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I. INTRODUCTION 



A. BACKGROUND 

In October of 1 996, the 40 m Infantry Division (Mechanized) lost its ability to 
transmit data electronically when the state’s primary electronic mail server was shut 
down in Rocklin, California. The reason for the server shutdown was based on the 
determination that the cumulative service being provided by the division’s automation 
system (known as the Reserve Component Automation System (RCAS)) was 
substandard. The decision was made to pull the plug on the e-mail life support system 
and shut down the server. Given this significant readiness impact, within days, the 
division’s Chief of Staff directed the division’s organic signal unit, the 240 th Signal 
Battalion to develop and provide the division with a means to communicate 
electronically. Through state funding, the division procured the hardware, software, and 
connectivity necessary to establish itself as an Internet Service Provider (ISP). 

Our mission, given to us by our sponsor, LTC Rod Barham, commander of the 
240 th Signal Battalion, was to develop an Intranet prototype which, first, because of the 
short time constraints, could be developed quickly and second, reflected the requirements 
and desires of the users to the extent possible, given the time constraints. 

We met with our sponsor on 19 December, 1996 (Appendix A — TRIP REPORT 
1) to further define the scope of our mission and to gather initial requirements. Following 
our initial development effort, we met with our customer to demonstrate our initial 
prototype efforts and to further define and refine user requirements (Appendix B - TRIP 
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REPORT 2). We delivered an operational prototype to our sponsor on 2 May, 1997 
which, because of the need, was put on-line and made available to users that afternoon. 

The goal of this thesis was to work with a military organization and focus on 
readiness improvement through the development of an Intranet prototype. 

B. WHAT IS AN INTRANET? 

An Intranet is a combination of a Local Area Network (LAN), Wide Area 
Network (WAN), and internet technologies (i.e., http and IP protocols, World Wide Web 
(WWW) browsers and servers, etc.) through which members of an organization, located 
anywhere in the world, can connect people and information electronically in order to 
more efficiently and effectively conduct business. The internal net or Intranet can be 
restricted to those authorized access by the organization. 

C. CONTENTS 

This thesis contains seven chapters and two appendixes. 

1. Chapter I Introduction 

This is the foundation chapter and gives a brief background followed by a thesis 
content section. 

2. Chapter II Intranet 

This chapter discusses the advantages of Intranet use followed by a discussion on 
the client/server model of computing. Hardware and software requirements for 
establishing an Intranet are also covered. The final section in Chapter II is a discussion 
about the information creation and consumption model. 
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3. Chapter III The Customer 

Chapter III discusses the history, organization, structure, and mission of the 40 th 
Infantry Division (Mechanized). The Reserve Component Automation System is the 
U.S. Army National Guard and Reserve office automation system. The RCAS system, 
which was fielded in its entirety in California (the first state to be fielded), went through a 
major program redevelopment following numerous cries of discontent from its user base. 
The fielding of the “old” RCAS system was halted while the program was reviewed and a 
“new” RCAS system emerged as a result. Federal funding for “new” RCAS components 
is expected in second quarter of FY98. The state and the division are working interim 
solutions (i.e., Intranet prototype) in order to provide the users with high quality 
electronic/digital service until the federal funding for the new system arrives. 

4. Chapter IV The Prototyping Process 

The methodology used for the development of the Intranet was the prototype 
model. This chapter initially contrasts the traditional waterfall model with the prototype 
model followed by a section discussing the benefits and drawbacks of using the prototype 
model. The scope of this thesis is also covered in this chapter. The Division’s current 
information operations are discussed and, finally, the adaptation of the prototype model 
to the development of a military Intranet is covered. 

5. Chapter V Identification of Basic Requirements 

This chapter discusses the methodology used to gather requirements. Also 
presented is a discussion on the requirements gleaned from meetings with the sponsor. 
These requirements were used in developing the prototype. 
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6 . Chapter VI The Prototype 

This chapter covers the actual Intranet prototype. Numerous screen shots are 
provided to give the reader the “look and feel” of the developed prototype. The 
discussion of the prototype is related to the sponsor’s requirements, which are presented 
in Chapter V. 

7. Chapter VII Recommendations for Intranet Operation 

It is imperative that the division establishes policy as soon as possible regarding 
the further development, implementation, and use of the Intranet. This chapter discusses 
Intranet policy and recommendations concerning policy areas which should be included 
in a division Intranet policy. This chapter also contains a section on Intranet lessons 
learned. These lessons learned are a compilation of ideas developed through the 
numerous readings done in this area. This section lists eight recommended steps the 



division should follow in order to insure success. 



II. INTRANET 



A. INTRODUCTION 

Chapter I provided a definition of an Intranet. This chapter will present some of 
the advantages of Intranet use. This will be followed by a review of Intranet 
technologies. This includes a brief mention of the client/server model which is the heart 
of the web-based functionality of an Intranet. Hardware and software requirements for 
setting up an Intranet are also covered in this chapter. Finally, a section is presented on 
information creation and consumption. 

B. ADVANTAGES OF INTRANET USE 

A recent study by Network World found that eighty-nine percent of organizations 
sampled already have implemented or will implement an Intranet strategy in the next 
twelve months [1.2]. The large percentage of organizations that have implemented or 
planning to implement Intranets have been attracted by the numerous benefits provided 
by Intranets. Some of these benefits include: 

1. Simplified Information Access 

With the use of an organizational web server and a client web browser, an 
unlimited amount of static and dynamic information can be accessible to the user. 
Organizational policies, procedures, regulations, and databases are just a few examples of 
the types of information that can be accessed on an Intranet. 

2. Enhancement of Communication and Collaboration 
Information flow improves with the capabilities of conducting on-line 

collaboration through real-time “whiteboarding” and near real-time messaging through 
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electronic mail. Multipurpose Internet Mail Extensions (MIME) is a mechanism that 
allows users to attach application specific files to electronic mail which are then 
recovered on the receiving end for review, update, or further processing. Applications 
like Microsoft’s Netmeeting allow users to conduct on-line chat room discussions and 
collective document preparation. Information dissemination is simplified for 
organizational command and control elements. 

3. Productivity Enhancement 

Combining the capabilities an Intranet set of tools provides postures an 
organization to become a more productive entity. Processing and accessing information 
by electronic means simplifies the communication process. Electronic mail allows users 
to respond on their time rather than having to respond on demand to an interuptive phone 
call. Collaborative tools allow groups who are geographically dispersed to brainstorm 
and come to consensus on team issues. Web pages allow department information 
providers the ability to quickly disseminate information. On the user side, the Intranet 
allows the user the flexibility to “pull” information, based on a need or desire to know. 
Examples such as these illustrate a work environment that allows individuals and teams 
to focus on their work tasks by providing a system that puts information literally at the 
fingertips of the organization. 

4. Decision Support 

One of the major strengths of an Intranet as a mechanism for decision support is 
that it facilitates access to distributed information and distributed access to desired 
information. This information can be in the form of data and models and can be obtained 
from different sources in a variety of formats and media, locally or remotely. The 
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Intranet provides a user-friendly mechanism for rapid access to information required for 
decision-making by facilitating the links between data, models and users. [2.2] 

5. Affordability 

One of the reasons Intranets are so appealing is the fact that web technology is 
inexpensive. The basic system configuration consists of a server hardware 
platform/operating system and WWW server software. On the user side, employees only 
need an inexpensive browser to navigate the information. A study conducted by U.S. 
Computer, and funded by Sun’s Internet Commerce Group, indicates that web 
technologies can reduce internal corporate networking costs by as much as $1 1 million 
over four years for a large network [2.3]. 

6. Ease-of-Use 

Another major driving force behind the growth of Intranets is that the technology 
is intuitive and easy to use. Little training is needed before employees are “up and 
running” on the Intranet. Using their browsers, employees use hypertext links to search 
for and access text, graphics, audio, or video. At a very basic level, this means 
organizations can hold down printing and distribution costs for documents that are now 
produced on paper, such as organization policy letters and standing operating procedures. 
C. INTRANET TECHNOLOGIES 

1. The Client/Server Model 

The WWW and Intemet/Intranet technologies are based on the client/server 
model shown in Figure 2.1. To truly understand how an Intranet operates, it is important 
to understand the concept of client/server computing. The client/server model is a form 
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of distributed computing where one program (the client) communicates with another 
program (the server) for the purpose of exchanging information [2.4]. 




Figure 2.1. Client Server Dialog [2.5] 



The WWW uses a distributed client/server architecture built around a message 
based on resource servers and client browsers as illustrated in Figure 2.1. Although it is, 
for the most part, transparent to the end users, browsing is a two-step process of 
downloading data from the server and then acting on it. This provides the opportunity to 
act on data with a browser or launch a new application for specific data types and, 
consequently, the behavior is easily extended. 

Key WWW specifications include the Hypertext Markup Language (HTML), 
Uniform Resource Locators (URLs), Multipurpose Internet Mail Extension (MIME) and 
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the HyperText Transfer Protocol (HTTP) [2.6]. These specifications are discussed 
below: 

• Hypertext Markup Language (HTML) - HTML is used when 
publishing a document that is to be displayed through the WWW. 

HTML is a set of simple syntax commands that describes how a 
document is structured. This language allows the user to define the 
parts of a document, but not the formatting, so that the browser used 
for reading the document can format it best to suit the user's display. 

• Uniform Resource Locators (URLs) - a URL is a complete description 
of an item, containing the location of the item you want to retrieve. A 
typical URL looks like this: http://jupiter.as.nps.navy.mil/40thdiv . The first 
item in the URL (the portion that ends with a colon) is the protocol 
used to retrieve the item. For this URL the protocol is HyperText 
Transfer Protocol. The two forward slashes that follow indicate that 
what follows is a valid host address. It can either be the text as shown 
or the actual corresponding IP address of the site. 40 th div, in this case, 
is the default homepage for the web site titled 40thdiv. 

• Multipurpose Internet Mail Extension (MIME) - MIME is an 
extension to the existing Simple Mail Transport Protocol (SMTP) 
standards that offer a standardized way to represent and encode a wide 
variety of media types, including textual data in non-ASCII character 
sets, for transmission via internet mail [2.7]. 

• HyperText Transfer Protocol (HTTP) - After it was decided to use 
hypertext as the standard format for WWW documents, a protocol that 
allowed these hypertext documents to be retrieved quickly was 
developed. This protocol is HTTP. HTTP is a simple communication 
protocol that allows the document it is retrieving to retain hyperlinks 
to other documents during download. 

Using Figures 2.1 and 2.2, a scenario can be presented to illustrate a typical 
process in an Intranet environment: user with access to the local area network via a direct 
connection or a dial-in capability has a web browser residing on his/her client machine. 
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Browser 




Figure 2.2. Browser/Server Communication [2.8] 

The browser reads a document written in HTML and displays it for the user, 
interpreting all the markup codes. When the user clicks on a hyperlink in an HTML 
document, the browser uses the HyperText Transfer Protocol (HTTP) to send a network 
request to a web server to access the new document or service specified by the hyperlink 
(i.e., service using server based programs). The client’s request is handled in one of two 
ways. If the request is for a document or data, the response involves the delivery of the 
document or data to the client browser. 

A second situation is if the user is requesting some type of service from the server 
(i.e., post data to a database, query database, server side processing, etc.). In order to 
access server programs and invoke them from a web client, the server uses a Common 
Gateway Interface. The function of the CGI is to interpret service requests from the 
server to server based programs. The Open DataBase Connectivity standard is a form of 
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CGI developed by Microsoft to allow browsers and servers the ability to interact 
remotely with server based database programs. Once the server services a request-based 
program, a response is sent back to the user’s browser (i.e., query results). When the 
response comes back to the user’s browser, the HTML interpreter displays the requested 
document. The displayed document contains hyperlinks with underlying URL locations 
for other web server based documents and data. 

Browsers can be configured to launch executable files the moment a server 
response is received. For instance, a request is made for an administrative form that 
resides on the server. The moment the file is returned to the browser, the browser 
invokes the executable command for the application residing on the client’s machine (i.e., 
administrative form preparation program) and launches the application. After completing 
the form, the user can immediately launch a mailer (both Internet Explorer and Netscape 
have mail clients that reside in the browser environment), attach the form as a MIME and 
send it to other Intranet users for action or additional processing. 

D. HARDWARE AND SOFTWARE REQUIREMENTS 

An Intranet can be tailored to the organization’s information requirements. The 
heart of an Intranet is the host or server. As mentioned previously, members of the 
organization will have access to the Intranet through the Local Area Network (LAN) or 
through other means such as dial-in access via a modem. 

Requirements: 

• server computer on LAN with appropriate web server software such as 

Microsoft’s Internet Information Server (IIS). Once the scope of the Intranet 
is defined, the server computer should have sufficient CPU, RAM, and Disk 
Storage resources to handle the expected load of “requests” from numerous 
client browsers accessing the server simultaneously. 
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• authoring software such as Microsoft Frontpage to create and update site 
content 

• browsing (client) software such as Netscape Navigator and Microsoft’s 
Internet Explorer for all users 

• other server software, such as mail server software, which will permit the use 
of electronic mail across the network 

E. INFORMATION CREATION AND CONSUMPTION 

The previous section implies that, from a purely hardware and software 
perspective, putting together an operational Intranet is not a difficult task. The difficulty 
resides in administering the Intranet so that it provides relevant, up to date and useful 
information to users. Chapter VIII covers Intranet operations and looks specifically at 
recommendations for Intranet and content control. Ultimately there will be a need to 
decentralize the process of Intranet control (i.e., Divisions delegate brigade web 
management to brigades, brigades to battalions, etc.) This, of course, only occurs after 
adequate training in web publication, content standards, etc. Figure 2.3 presents an 
information development and consumption cycle [2.9] that is prevalent in an Intranet 
environment. This model assumes a decentralized posture within the organization. 
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Collaborate 
& Publish 



Gather 

Content 



Analyze &Create 



Figure 2.3. Information Production and Consumption Cycle [2.9] 



A typical member of an organization operates in the context of an information 
creation and consumption process. His/her primary product is new information in the 
form of memorandums, budgets, proposals, analysis, presentations, work requests/orders, 
etc. Each of these “raw” forms of information requires some action on the part of the 
information recipient. This action may be some combination of content creation, 
analysis, data access, collaboration, and publishing [2.9], which contributes to the overall 
knowledge base of the organization. 

The first step in this iterative process is to gather content worthy of further 
analysis and, ultimately, to publish it on the organization’s Intranet. An individual- 
identified to be the responsible person (held accountable for web-publishing and content) 
for each entity (i.e., division webmaster, brigade webmaster, etc.) will gather information 
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from many sources. As information is collected and analyzed, the webmaster begins to 
create new content using familiar publishing tools like Microsoft’s FrontPage. In some 
situations, content creation will be a collaborative effort, where team members work 
together to come up with content. Once the content is published, the information is 
made available to others on the Intranet, which drives them into the creation and 
consumption cycle. 

The tasks within the creation and consumption model can be further broken down 
and discussed: 

1. Content creation 

Some documents, by their nature, require frequent revisions, where others will 
only have to be updated periodically. Examples of documents which will require 
frequent updating include: training schedules, commander’s guidance, staff notes, 
operation orders, intelligence summaries, etc. Documents which will only be updated 
periodically include: policy letters, standing operating procedures (SOPs), soldier 
packing lists, inspection checklists, etc. The dynamic characteristics of any organization 
cause constant change in current information. In order to maintain relevant, meaningful, 
and up-to-date information, the webmaster at each entity level has to keep a pulse on 
what information is being provided to its subscribers. With the need to change content 
often, it is imperative that the webmaster be provided with the friendliest publishing tools 
available. 

2. Analysis and Data Access 

Office application suites today allow the user to save text documents, 
spreadsheets, and presentations in HTML format. Databases can be tied to web servers 
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via common gateways such as Microsoft’s Open Database Connectivity Standard 
(ODBC). These functions allow Intranet users to easily access and analyze budgets, 
proposals, presentations, etc. The ability to access database records gives authorized 
users the capability to remotely update those records and conduct analysis on existing 
records through queries. The ability to access pertinent information quickly allows the 
user to conduct analysis more quickly and thoroughly. Providing immediate access to 
relevant documents drastically reduces the user’s decision cycle. 

3. Collaboration 

Organizational documents often have many authors who work together in order to 
produce a collective product. The Intranet environment allows users to review, comment 
on, and update working documents before final versions are published. 

4. Publishing 

One of the greatest benefits of having an Intranet is the ability to quickly 
disseminate information. Once created, there is an enormous amount of information that 
needs to be shared widely within an organization, such as operations orders, policies, 
procedures, scheduling, and budgeting information. Current application publishing tools 
make converting this kind of information into HTML documents and posting them on an 
Intranet a very simple process. 

F. CONCLUSION 

This chapter has covered a broad range of Intranet related topics including the 
benefits provided by an Intranet, the client/server Intranet architecture, hardware and 
software requirements necessary to implement the Intranet and, finally, a view of how an 
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organization develops and consumes information. The following chapter focuses on the 
customer, the 40 th Infantry Division (Mechanized). 
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III. THE CUSTOMER 



A. INTRODUCTION 

As mentioned previously, a large part of the motivation for this research was to 
develop a product that would improve the readiness of a military organization. Also 
mentioned earlier was the fact that a search for a military customer was conducted 
immediately. The search included those organizations that had an existing technical 
architecture, which could support the implementation of an Intranet. 

This chapter focuses on the customer, the 40 th Infantry Division (Mechanized) of 
the California National Guard. A brief history of the Division is provided, followed by a 
look at the Division’s organization, structure and mission. The Reserve Component 
Automation System (RCAS) is the administrative system for Army National Guard and 
Reserve. It is a Wide Area Network (WAN) that is a worldwide system proposed to 
provide interconnectivity for all guard and reserve units. RCAS is a multi-billion dollar 
information systems acquisition program, which, until fielded in California, leaves a void 
in the Division’s ability to conduct digital information sharing. In this chapter, the RCAS 
program is addressed first followed by a discussion of the 40 th Division’s problem of 
degraded information operations. Finally, a discussion the proposed solution, of which 
the development of a division Intranet is a major part. 

B. BACKGROUND 

1. History 
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The 40 th Division was organized at Camp Kearney, near San Diego, California, on 
25 August 1917, and was composed of National Guard organizations of the states of 
Arizona, California, Colorado, Nevada, New Mexico, and Utah. 

The division fought with distinction in World War I, World War II, and the 
Korean War. The Division has four recipients of The Medal of Honor, which is our 
country’s highest award for bravery. In addition to the division’s gallant federal service, 
the “Citizen-Soldiers” of the 40 th Infantry Division have responded to countless state 
emergencies, providing service to the state of California. Some of the state emergencies 
where the Division distinguished itself include the Folsom Prison riots (November, 

1927), Long Beach earthquake (March, 1933), Sacramento floods (December, 1950), 
“Watts Riot” (August, 1965), Los Angeles Civil Disturbance (1992) and the Northridge 
Earthquake (January, 1994). 

2. Organization 

The 40 th Infantry (Sunburst) Division is headquartered at Los Alamitos, 

California. Figure 3.1 is a hierarchical depiction of the 40 th ’s organization. The Division 
follows what is known as the active Army’s J-series Table of Organizational Equipment 
(TOE). A TOE gives like units the same authorization for personnel and equipment. The 
division is depicted at the top with an XX (indicates a division size element) symbol 
above the symbol for a mechanized infantry unit. The division consists of three 
maneuver brigades (each with three battalion size elements), an aviation brigade 
(consisting of four aviation battalions and one air cavalry squadron), an artillery brigade 
(with three battalion and two company sized elements), an engineer brigade (consisting 
of three battalions), and a division support brigade (with one main support battalion and 
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three forward support battalions). Also organic to the division are an air defense 
battalion, a signal battalion, a military intelligence battalion, a Military Police (MP) 



XX 
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company, a chemical company, a long-range surveillance company, and the division 
band. 

3. Structure 

Like most military organizations, the mechanized infantry division is 
hierarchically structured. Each battalion through division size element (entity) has a staff 
of primary officers who assist the commander in planning, coordinating, preparing, and 
executing operations within and outside the division. Literally thousands of processes 
(both formal and informal) are executed by division entities on a daily basis. In order to 
control the different processes, battalion through division size organizations break down 
these operations into four primary task groups. A responsible officer is chosen by the 
commander to lead these operational groups at each entity level. These groups are 
labeled staff elements and are numbered one through four with five (civil affairs) and six 
(communications and computers) located at division level and above units. Figure 3.2 
depicts the hierarchical structure of a typical staff. The Chief of Staff (division level and 
above) or Executive Officer (XO) (brigade level and below) presides over the staff at 
each entity level down to and including battalions. There are a total of seven brigades 




Figure 3.2. An Army Staff 
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and twenty-three battalions in the 40 th division. Each of them possesses a staff similar to 
the one depicted in Figure 3.2. 

Below is a very brief description of each staff element’s area of responsibility. 

The intent is to give the non-military reader an introduction to military staff areas of 
responsibility. 

• G-l/S-l(PersonneI): Responsible for all personnel actions in the division, to 
include awards, promotions, pay inquiries, and personnel replenishment 
planning in a combat environment. If it has to do with personnel actions, it is 
the G-l/S-1 ’s area of responsibility. 

• G-2/S-2(InteIIigence): The intelligence section of an organization focuses on 
the threat. The threat may be local gangs that present a potential threat to a 
military installation or an enemy combat foe with armored tanks and artillery 
pieces. The G-2 is responsible for keeping the commander and the rest of the 
staff abreast of the capabilities and limitations of the threat and what the threat 
is doing. In a garrison environment, the G-2/S-2 is responsible for security 
awareness and measures to combat the threat in that environment. 

• G-3/S-3 (OPS/Training): The G-3 is the operations and training officer. 
Planning, preparing for, and executing training events is one of the G-3/S-3s 
many responsibilities. The OPS/training officer’s focus during peacetime is 
on the unit’s Mission Essential Task List (METL). A unit’s METL are those 
tasks it must be able to perform in order to insure a combat level of readiness. 
The G-3/S-3 writes the operations orders (OPORDS), issues fragmentary 
orders (updates to OPORDS) and coordinates the other staffs activities in the 
absence of the Chief of Staff. 

• G-4/S-4 (Logistics): The logistics officer is responsible for all logistical 
matters in the division. The G-4 arms, fixes, fuels, feeds, houses, and 
transports the division. Like the other staff elements, the G-4 is heavily 
involved in planning operations. In order for the G-3 to consider an 
operationally feasible plan, the G-4 must certify that the plan is logistically 
supportable. 

The 40 th has subordinate organizations in five different states (Arizona, California, 
Montana, Utah, and North Dakota). The 40 th division accounts for nearly eighty percent 
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of the National Guard soldiers in the California. Figure 3.3 provides major command 
locations of the Division’s major commands throughout California. 
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3rd Brigade 
Aviation Brigade 
Engineer Brigade 
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Division Support Command 
Division Artillery 
40ID (M) Headquarters 
2nd Brigade 



Figure 3.3. 40 th Division Units in California [3.2] 



4. Mission 

The 40 th Division has a dual mission. Their federal mission is to provide combat 
ready forces to the Department of Defense. In order to do this, the division conducts 
pre-mobilization training to maintain a level of readiness so, when called upon to 
mobilize, she can do so on short notice. Once mobilized, the division must conduct the 
necessary post mobilization training to further prepare itself to deploy, fight, and win. 

The division’s other mission is to provide military support to civil authorities. 
The division answers to the Office of The Adjutant General (OTAG) and to the state’s 
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Governor. Both are located at the state’s capitol in Sacramento. The state of California 
is the most disaster-prone state in the nation. The division’s mission summary list for 
1996 include 600 counter-drug, 33 emergency shelter, 21 fire, 1 1 search and rescue, 3 
flood, and 16 other support type missions [3.3]. 

C. RESERVE COMPONENT AUTOMATION SYSTEM 

1. Background 

The Reserve Component Automation System (RCAS) is an Army National Guard 
and Reserve component sustaining base/office automation system. The system was 
designed to meet the day-to-day office automation requirements to the Army’s reserve 
component. The design of the system significantly enhances the reserve component’s 
mobilization preparedness and execution. 

In February 1995, amidst reports indicating program problems (i.e., cost and 
schedule overruns, system performance problems, customer dissatisfaction), Lieutenant 
General Edward D. Baca, Chief of the National Guard Bureau, assembled a “Red Team” 
to conduct an objective assessment of the program status of the RCAS. The team was 
chartered to identify problem areas and to develop courses of action necessary to put the 
program back on a reasonable development and implementation path. The “Red Team” 
recommended significant changes in the RCAS program in many program areas [3.4]. 
Following the recommendations, the RCAS Validation Assessment Team (VAT) was 
established to validate and substantiate the Red Team’s findings. The charter of the VAT 
was to identify, assess, and develop a complete system solution which was consistent 
with the Red team’s recommendations and satisfied user-defined requirements of the 
United States Army Reserve Component, within budget. [3.5] 
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In order to give the reader a perspective of where the program was when General 
Baca called for the assessment, the following bullets are provided which characterize the 
program at that point in time: 

• Fielding of the original system began in 1987. Nearly thirty percent of the 
projected 4000 plus sites had been fielded when deployment of the system 
was halted in 1995. California was the first state fielded. A total of 387 units 
and activities were fielded with the original RCAS in California. 

• Difficulties in managing the users and their needs and expectations led to 
changes in the requirements, which ultimately impacted software design goals 
and objectives. This resulted in a projected two year delay in the completion 
of the first block of software. 

• The original architecture is a Unix based client/server environment. The 
system called for x-terminal client machines with no local capability (i.e., 
resident CPU) for application processing. There were complaints about the 
user’s familiarity with Unix based applications and the Unix command line, 
particularly for soldiers who only drill one weekend a month. 

• The system was used primarily as an e-mail system. There were 5 regional 
mail hubs, which routed mail traffic down to the unit level. Each unit 
maintained its own dedicated Unix based server. The original solution 
required units to dial-in to one of the five regional mail hubs in order to 
upload and download mail. The original architecture using these dedicated 
Unix servers with little or no redundancy at some sites was very susceptible to 
single point failures. 

• The original system architecture called for a distributed database with data 
servers physically located at the unit or end user level. The initial plan called 
for the procurement and implementation of the anticipated 4,700 locations 
with costly specialized hardware and software. An illustration of the original 
architecture is presented in Figure 3.4. 
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Figure 3.4. RCAS Original Architecture 



At the time the “Red Team” was formed, the RCAS program was suffering from 



not being in tune with the requirements and needs of the customer. 
2. Scope 



The Reserve Component Automation System is a 2.5 billion-dollar program. 



Rather than dwell on the problems the program has suffered in the past, a chose was 
made to look to the program's future and the recommendations made by the Red team and 
the VAT. On 19 July, 1995, the RCAS General Officer Steering Committee (GOSC), the 
overall decision-making body for the RCAS, directed the RCAS Program Management 
Office (PMO) to implement the Red Team/VAT recommendations [3.6], 
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The major restructuring of the RCAS program in 1995, based on the assessment 
team’s recommendations caused significant changes in the way the program was being 
run. The focus of the remainder of the discussion on the RCAS system centers on the 
following areas: Red Team/VAT recommendations in the areas of system architecture, 
system data and applications, and system deployment. 

3. System Architecture [3.7] 

The Red Team/VAT established objectives before they considered different 
architectural and design alternatives for the new system. Those objectives included: 

• Use of Industry/ DOD standards 

• Maximum use of Commercial Off The Shelf (COTS) and Government Off 
The Shelf (GOTS) hardware and software 

• Meet the needs of the users 

• Use mainstream technology 

• Use scalable components with scalable architecture 

• Make architecture adaptable to rapidly changing technology 

• Ensure compliance with the Army’s Technical Architecture (AT A) and 
Defense Information Infrastructure’s Common Operating Environment (COE) 

• Make the architecture data-centered 

The resultant architecture recommended by the VAT and approved by the RCAS 
General Officer Steering Committee (GOSC) is in-line with the objectives established 
prior to architecture formulations. The architecture can be characterized as a 
server/workstation architecture and is presented in a very broad view in Figure 3.5. 

Scalability is probably the first noticeable characteristic in Figure 3.5. Because of 
the different sized organizations, the sites are configurable to suit the needs of the user. 
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Most State Area Command (STARC), Regional Support Command (RSC), and Direct 
Reporting Commands (DRC) are considered large sites (76+ workstations). These major 
hubs provide the WAN connectivity to other STARCs, RSCs, and DRCs. Other 
configurable variants include medium sites (17-75 workstations), medium sites (9-16 
workstations), and small sites (1-8 workstations). 

The server side of the server/ workstation architecture is based on Microsoft’s 
Windows NT Server 4.0, which is a network operating system. The NT Servers which 
are located throughout the architecture provide such system functions as centralized 
administration and management, e-mail, LAN printing, file sharing, configuration 
management, virus protection management, and system and file security [3.9]. 
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The implementation of any Windows NT server design is based on a domain 
structure. A domain is a set of servers, defined as a logical group, which holds the user 
account/domain database. A domain is the basic unit of centralized administration and 
security. NT server provides the connectivity, reliability and availability, base system 
services and administrative tools necessary to deliver critical information across a large 
distributed network of computers. [3.10] 

All workstations in the workstation/server environment are based on Personal 
Computer (PC) architecture with a Pentium processor, 16MB RAM, an IDE Enhanced 
controller, and a 1 GB hard disk. The workstation operating system is Microsoft 
Windows NT workstation. NT workstation provides security at the C2 level which 
includes Identification and Authentication (I&A), Discretionary Access Controls (DAC), 
Audit and Object Reuse. This provides users with the capability to restrict access to data 
on a read/write basis and administrators with the ability to monitor system usage. The 
Office Automation (OA) suite (Microsoft Office) has the friendly graphical user interface 
(GUI) that users are familiar with. All the application files in the OA suite can be 
attached to a mail message using Multi-purpose Internet Mail Extension (MIME) 
(Chapter 2) and sent using the resident mail client. A closer look at the architecture 
indicates the RCAS will operate as two separate systems, one for classified or “Red” 
processing and one for unclassified or “Black” processing. Figure 3.6 shows the Red 
system solution. 
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removable drives 

Figure 3.6. RCAS Red Architecture Solution 

The “Red System” is characterized by its use of secure data devices (i.e., STU- 
III) operating at each entity level between transmitting and receiving units. The 
architecture calls for stand-alone workstations at all echelons with removable media (i.e., 
hard disks). 

The “Black System” solution side of the RCAS system is depicted in Figure 3.7. 
The NIPRNET is DOD’s unclassified but sensitive Internet Protocol Router Network and 
serves as the network backbone for RCAS. The RCAS is vulnerable in two areas. First, 
the network has no means to safeguard the integrity of traffic and protect it from 
disclosure. The second is that RCAS nodes connected to the NIPRNET are vulnerable to 
attack from the Internet. 
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In order to protect the integrity of traffic, the architecture calls for the use of 
Digital Encryption Standard (DES) packet encryptors. Every workstation will be 
equipped with PC card slots. The DES packet encryption devices are credit card size and 
uniquely identify message traffic senders and receivers. The cards are inserted into the 
card slots in order to encrypt and decrypt messages. A COTS firewall at the RCAS 
Network hub will provide managed access to the RCAS system from the internet. 




Figure 3.7. RCAS Black Solution Architecture [3.12] 

4. System Data and Applications 

If you recall, one of the objectives of the VAT, when considering the RCAS, was 
to make the architecture data centered. The power and utility provided a user, when able 
to query database management systems, can not be underestimated. The ability to access 
local or remote databases provides the user with a powerful decision support tool. Figure 
3.8 provides an illustration of how the “data centered” components will be incorporated 
in the RCAS architecture. 
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LOCAL REPLICATION 
for query and local reporting 



Figure 3.8. RCAS Database Architecture [3.13] 



A DataBase Management System (DBMS) is established at State Area 
Commands (STARC) and Major United States Army Reserve Commands (MUSARC). 
The DBMS at this level will also be known as the DataBase Of Record (DBOR). These 
DBORs will be tied to other replicated hosts including hosts at the National Guard 
Bureau (NGB), the United States Army Reserve Command (US ARC) and Mobilization 
stations throughout the guard and reserves. Applications residing on local level machines 
will allow the local user to access and query the DBOR. Batched transactions will allow 
the DBOR to update the DBMS at the intermediate (Brigades and Divisions) and lowest 
levels, to provide the user with an up-to-date replication of the DBOR. This provides the 
user with a local query and reporting capability. 
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5. RCAS Deployment 

Deployment of the system is defined as those functions necessary to manage and 
distribute RCAS automated data processing (ADP) hardware, telecommunications 
equipment, and the office automation or pre-loaded software to the designated (4,000 
plus) end user sites or locations [3.13] Figure 3.9 gives the locations of the 
approximately 4021 RCAS sites, which include 10540 units. Figure 3.10 gives echelon 
unit quantities by site size and totals the number of sites, units, and workstations. 
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ECHELON UNIT QUANTITIES BY SITE SIZE 
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Figure 3.10. RCAS Unit Distribution [3.15] 



D. CURRENT STATUS 

The intent of this section is to give the reader a current status of the “post-old 
RCAS” and “pre-new RCAS” situation in the state of California. As was mentioned 
previously, California was the first state in the U.S. fielded with the old RCAS system. 
The fielding of 387 Unix based servers with ancillary equipment (i.e., x-terminals, 
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printers, etc.) to as many units and activities, was done at an estimated cost of nearly 
$100 million. The state's number one priority for fielding the old RCAS system earned it 
a very low priority (last state to be fielded) for federal funding of the new system. 
Information management representatives from the state headquarters do not expect 
program funding for equipment, installation, fielding, and training until 2 nd Quarter of 
fiscal year 1998. The 387 units and activities throughout the state were totally reliant on 
the server-based office applications when the decisions were made in 1995 to shift to a 
PC based workstation/ NT server environment. Very few of the organizations had PCs to 
conduct office administration tasks. The ability to share data electronically with adjacent 
units, via a network, was eliminated when the Rocklin regional mail hub was shut down 
in October, 1996. Since then, the state and the division have aggressively pursued 
information operations initiatives with state funding to improve their ability to pass 
information in a quick and efficient manner. The state's initiatives are in-line with the 
architectural requirements for new RCAS system, (i.e., MS NT based, MS Office, etc.) 
The state is posturing itself for new RCAS using state funding to come up with interim 
solutions to their degraded information operations. Some of the initiatives that have been 
enacted include: 

• The purchase and issue of two (in some cases only one) or more PC 
workstations to each of the 387 units and activities throughout the state 

• The development of a web-based Division Intranet (this thesis) which has 
since been expanded into a State-wide Intranet called the “Grizzly Net” 

• The establishment of a Primary Domain Controller (PDC) at the state 
headquarters which will be the PDC for the state's Wide Area Network 
(WAN) 



34 



• The establishment of six Back-up Domain Controllers (BDC), one each at the 
following locations: San Francisco, Stockton, San Luis Obispo, Los Angeles, 
and Sacramento. Each of these BDC sites will have a dedicated T-l 
connection with the PDC in Sacramento. Each of the BDC sites is being 
equipped with a modem bank to allow units without a dedicated line 
connectivity to the network. 

• The establishment of 1 1 subnets (organizations with 17-99 workstations) off 
the states WAN 

• The development of a tactical network 

These are just some of the many initiatives ongoing in the California National 
Guard to improve the current state of information operations and to posture itself for 
program funding and fielding of the RCAS system in 2 nd Quarter of FY98. 
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IV. THE PROTOTYPING PROCESS 



A. INTRODUCTION 

To better understand the potential contribution the prototyping process can have 
on development of a prototype, there must first be a definition of what the process entails. 
Next, a review of the project scope and the current operating environment will set the 
stage for determining how best to modify the prototype process to meet the division’s 
needs. 



B. THE PROTOTYPE DEVELOPMENT MODEL 

A prototype is defined as a preliminary working version of an information system 
for demonstration and evaluation purposes. It follows that prototyping may be defined as 
the process of building an experimental system quickly and inexpensively for 
demonstration and evaluation so that users can better determine information requirements 

[4.1] . The primary purpose of the prototyping process is “to reduce time and expense in 
building quality systems” and “mandates a philosophy of incremental system 
development that includes end users in the assessment of emerging system capabilities” 

[4.2] . Understanding this process and its potential benefits and pitfalls can best be 
accomplished after a review of the traditional waterfall development model. 
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Figure 4.1 displays the typical steps in the waterfall model. This display shows 
seven steps required in developing a business application, with each step being iterative 
with the step before it. This is to say that the product is verified as it moves from one 
phase to another, and validated/corrected after arrival at each new phase [4.3]. 

Because the waterfall model has been in widespread use since the 1970’s, its 
advantages and disadvantages have been widely documented. The model is well known 
for bringing much needed organization to very large projects. The rigorous execution of 
each phase coupled with the validation and verification processes often leads to 
monumental management effort, high costs, project delays, high maintenance costs, 
obsolete products and, worst of all, products which no longer address the central needs of 
the customer [4.1, 4.3]. 
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By comparison, the basic prototype model presented in Figure 4.2 is designed to 
include user feedback early in the development cycle. The first step places emphasis on 



capturing the most basic of customer requirements to be used in developing the initial 




Figure 4.2. The Prototype Model [4.1] 



prototype. Step two also involves speed. The developer need quickly create a working 
prototype, even if it is a shell with only restricted application, and return it to the 
customer. Next, the end user will use the prototype and make recommendations for 
revision. Step four involves revision of the prototype per the user’s requirements. 
Completion of this step is followed by an iterative move back to step three until the 
customer is satisfied that all requirements for the system have been met [4.4]. 

Philips electronics envisaged the following benefits from use of rapid prototyping 
in software development for their products [4.5]: 
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• Early Customer involvement 

• Improved specification quality 

• No ‘dead-end’ demonstrations 

• Shorter time to first product drops 

• User friendly systems to the customer 

• Less defects in latter phases of the lifecycle (and, thus, lower maintenance 
costs) 

Additional benefits include [4.6, 4.7, 4.8, 4.9]: 

• Better user interface development 

• Continuous customer involvement 

• Reduced development costs 

• Very well suited for smaller applications 

• Ensures nucleus of system is right (i.e., clarifies requirements and more 
exactly meets users need) 

• Reduced levels of effort for staff 

• Increased user enthusiasm 

• Validation and verification are inherent 

• Evolutionary nature enhances flexibility and scalability in a rapidly 
changing environment 

This last point is a key consideration in choosing to use the prototype process. By 
recognizing the prototype process as involving the capture of human activity systems vice 
as a science or engineering tool [4.10], the processes suitability in situations with ill 
defined or rapidly changing environments may be viewed. Exposing the prototype to 
the actual environment can be seen as a learning method. As displayed in Figure 4.3 
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[4.1 1], this “learning process” is incremental in nature, as the product is iteratively 
reconciled against customer needs. It is this incremental learning which allows the 
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Figure 4.3. Nested Development Loop [4.11] 

prototyping process to respond to rapid change in the environment, providing maximum 
flexibility in the maintenance phase of the lifecycle [4.12]. The iteration concept will be 
explored more fully later in the chapter. 

Lest the prototyping process appear to be a panacea, the following list of potential 
problems is presented [4.13, 4.14, 4.15, 4.16]: 

• Essential elements in system development may be glossed over (i.e., 
documenting system) 

• Prototype may prove functionalities that are unattainable under real time 
usage of assets 

• May lead to end user misunderstanding (user doesn’t understand ‘Under 
Construction’ look and feel) 

• Clean up of prototype may not occur (i.e., leaving unused/out-dated materials 
in place) 

• Prototype may capture only rudimentary requirements (i.e., incomplete 
iteration) 

• Difficult to maintain user enthusiasm, especially in the face of overselling the 
prototyping process. Can lead to dissatisfaction 

• Difficult to plan and control; not suitable for large projects 
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• Design standards may be hard to enforce 

• Potential for loss of information security (Security measures discussed in 
Chapter VII) 

Another well-known pitfall is that throwaway prototypes often are not thrown 
away. This raises the discussion of throwaway prototyping verses evolutionary 
prototyping. The key advantage to creating a throwaway prototype is that actual 
requirements are still gathered via prototyping, but design is conducted separately, under 
more structured conditions. This action ensures better documentation, but earns the 
dangers inherent in traditional methods. The evolutionary process strives to develop a 
working model that will become the desired system, and is the basis for most of this 
chapter’s material [4.17]. As mentioned in the above list, evolutionary prototyping can 
suffer degradation of quality attributes such as performance, design quality and 
maintainability [4.18]. In this instance case, the throwaway prototype option was 
rejected for reasons that will be discussed in Chapter VI. 

C. SCOPE 

The scope of the proposed prototype encompasses the building of a baseline 
Intranet for the 40 th Mechanized Infantry Division. The prototype includes web pages 
down to the Battalion level, designed in a standardized manner. Rather than a “do all, 
end all” system, the prototype will contain only some key functions identified in Chapter 
VI, and will be turned over to the end user for continuous revision by members of the 
division as described in paragraph D and Figure 4.4. 
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Instead of the fourth generation tools typically used in prototype development, 
this prototype will be built with Commercial-Off-The-Shelf (COTS) web editors, word 
processors and database suites in wide use by the members of the division. 

D. CURRENT INFORMATION OPERATIONS 

The current means of managing information is time honored and effective, if not 
efficient. The predominant information exchange capability between and within units is 
the telephone. With the addition of the facsimile machine, this medium has expanded 
from a coordination tool, to one capable of transporting all manner of management 
information. MUX and FM facsimile equipment now available at the division level 
ensure this capability is available even in the field environment. 

Computers have also aided dramatically, enabling an interactive medium via the 
electronic file. Information management systems have been developed for all major 
resource management programs to include supply, maintenance, personnel and 
operations/training control. These systems allow inter-echelon exchange of information 
via file passing/updating by disk or download. 

Guard Mail, U.S. Mail, and expedited shipping means are also available for the 
physical transfer of paper and disk versions of information. 

Finally, meetings and other face to face coordination are still a highly effective 
means of ensuring information is passed correctly, requirements are understood and 
orders will be complied with. 

As mentioned, these methods may be used effectively, but suffer in terms of 
efficiency. Among the limitations of these methods is susceptibility of physical medium. 
While in transit, reports and other forms of information may be exposed to wrong parties 
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as control of the medium is lost after shipping/faxing. Anyone familiar with office 
management doubtless can relate stories of lost phone messages, compromised 
information files and unreceived materials. 

Some important materials need not only be hand delivered, but also will require 
on-site review to ensure adequate and correct submittal. An example would be 
processing of unit readiness information or the coordination meetings prior to a drill 
period. The costs involved in this type of interchange are twofold. First, the actual cost 
of traveling, be it borne by the unit (TAD funds), or the individual soldier. Second, the 
requirement to be at the same place and time represents a major opportunity cost, 
especially when travel time is considered. 

Similarly, phone and inter-unit meetings suffer from lost opportunity costs. 

While the timing of a meeting or a phone call may be optimal for the initiator, the other 
participant(s) may not be prepared to deal with the issue at hand, or may have more 
pressing requirements. Moreover, while methods like electronic file passing allow 
interaction, it is not real-time interaction. In short, these “information push” methods do 
not allow optimization of information and personnel across time and space for all parties. 
E. ADAPTATION OF THE PROTOTYPING PROCESS FOR A MILITARY 

INTRANET 

Perhaps the paramount requirement in successfully adapting the prototype process 
for any Intranet, military or otherwise, is to recognize that the process will be continuous 
throughout the life of the Intranet. Because content requirements, intended purpose of 
the Intranet, and number and types of users will change with the organizational 
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environment, the flexibility provided by the nested development loop identified in Figure 
4.3 will prove invaluable in providing the needed flexibility. 



TOTAL SCOPE : FULL SCALE SYSTEM FUNCTIONALITY 




GROWTH BY 
EXTENWON 



Figure 4.4. Migration of Scope [4.19] 

As mentioned above, the prototype delivered to the 40 m Division provided only 
minimal functionality and represents the prototype initial effort identified in Figure 4.4 . 
It will now become incumbent upon the division staff to expand the prototype via what is 
dubbed Black Border Management [4.19]. A section in Chapter VII will be devoted to 
the role of the Division Information Management Advisory Council (DIMAC) in 
managing and controlling this growth. Initially, the DIMAC will set basic policy and 
approve changes to the prototype as depicted in Figure 4.5. 
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REQUESTS 




Figure 4.5. DIMACRole 

As the basic policies and procedures are identified, responsibility for development 
and maintenance of content will shift to the end user. At this stage, the prototyping 
process matures into an end-user development process, allowing the individual units, 
commanders and staff sections to provide and manage the content they deem most 
necessary under a changing environment. This represents the major content change to the 
standard prototyping process identified in Figure 4.2 above. It should be noted that the 
DIMAC still maintains control over the basic prototype design and content issues as 
shown in Figure 4.6, thus providing the division commander control over the Intranet 
prototype. 

F. CONCLUSION 

The prototype model has been introduced in a manner which provides comparison 
to more rigid development procedures. The major advantages, and those important to the 
Intranet project, are scalability, better user interface and satisfaction, and more flexibility 
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Figure 4.6. Modified Prototype Model 



in the face of uncertain needs. The last advantage is enhanced when one realizes that the 
Intranet content will be ever changing, relying on end-user development after delivery, 



and providing considerable flexibility. 
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V. IDENTIFICATION OF BASIC REQUIREMENTS 



A. INTRODUCTION 

This chapter will explore the background and relationship developed with the 
sponsor and the 40 th Infantry Division (Mechanized), the methodology used for gathering 
requirements, and a comprehensive discussion of the requirements used to generate the 
prototype discussed in Chapter VI. 

B. BACKGROUND 

In October 1996, the development team witnessed a demonstration of an Intranet 
designed for a Naval Postgraduate School application. This demonstration sparked an 
interest in the Intranet development technology and process. In an effort to find a 
relatively local military sponsor, the team visited a California National Guard tank 
battalion unit based at the former Fort Ord, California. During this visit, the team 
discovered the shortfall in network computing resulting from the closing of the RCAS 
system as discussed in Chapter I. It was also discovered that the 40 th Infantry Division 
(Mechanized) was in the process of distributing personal computers and establishing a 
dial-in network, and points of contact were gathered which eventually led the team to 
LTC Rod Barham, the project sponsor. 

Initial contact was made with LTC Barham, who proved more than interested in 
developing a web for use by his division, and spoke of an ongoing effort to create a 
division BBS. A system requirements meeting was scheduled for December, resulting in 
the trip report presented in Appendix A. After discussions with LTC Barham’s BBS 
project point man, SSG Greg Holmes, it became obvious that the focus of effort to that 
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point was to set up the dial-in network to share information from the Logistics Automated 
System Support Office (LASSO) and establish e-mail accounts for key users. The 
broader issue of a division-wide information distribution system was not yet being fully 
addressed by these efforts [5.1]. 

C. PERSPECTIVE 

Clearly, what was needed was a design plan incorporating the entire division, and 
absorbing the LASSO efforts as a portion of the larger system. The team discussed the 
need with LTC Barham, and it was agreed that this was the correct course of action to 
take. However, even the most cursory review of the information distribution system 
currently in use by the division indicated a problem scope well beyond the capabilities of 
a single thesis team. Accordingly, it was decided to limit the scope of the project, as 
discussed in Chapter IV, and three requirement areas were identified. First, a full scale 
Intranet static design would need to be completed. Second, additional functionality will 
be provided on a limited scale. Lastly, an effort would be made to arrange for follow-on 
students to continue to address functionality issues with the division. While this last 
requirement was successfully met, it is not the subject of this thesis and will not be 
discussed further. However, the first two requirements will be more fully explained in 
the below paragraphs. 

D. REQUIREMENTS 

Chapter IV briefly delved into the vast variety of current information management 
methods practiced at the division and discussed the key limitation of the lack of ability to 
optimize information and human resources across the time and distance continuum. 

While the information distribution systems were too many to diagram and consider, it 
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became apparent that the basic design for the proposed Intranet would need to provide the 
means of augmenting or replacing some of these methods and systems. To meet this 
requirement, the design would need to move the user from an initial “home page” 
through the various layers of command, with links to appropriate staff sections and 
activity pages at each layer. Further, it was decided that the Intranet design should be 
simple, have a consistent look and feel throughout, and be free of “bells and whistles” 
requiring the user to have fast modems or suffer extreme download times. These issues 
will be more thoroughly explored in Chapter VI, discussion of the actual Intranet 
prototype. Also, the Intranet would act as a template to ensure standardization, and 
should be accompanied with recommendations as to content control policy and successful 
use, as discussed in Chapter VII. Lastly, it was decided that the prototype would be 
designed with, and would need to be used in conjunction with, the Microsoft Office 
family of applications, already the standard at the division. This was done both to ensure 
the ultimate portability of the prototype, to address compatibility with local division 
information systems already developed, and to take advantage of a preexisting level of 
expertise in use of these tools. 

Next, the initial requirements meeting addressed narrowing the number and kinds 
of functions to be built into the prototype Intranet once designed and developed. The first 
of these functions would be a personnel database to augment the SIDPERS database and 
provide more flexibility in reporting and data mining. The context level Data Flow 
Diagram (DFD) in Figure 5.1 illustrates the current system for retrieving information 
from the SIDPERS database. It should be noted that the major inefficiencies here are 
twofold. 
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Figure 5.1. SIDPERS Procedures 



Figure 5.2 shows that the process of submitting changes to the SIDPERS database 
is extremely cumbersome, sometimes involving providing a faster and more simplified 
process for making inquiries and providing a more up to date database from which to 
inquire and reconcile against the SIDPERS database. The team was to make no effort to 
link this concept vehicle to the actual SIDPERS database. 
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Figure 5.2. Level Zero Diagram of SIDPERS Procedure 



It was also requested that the team look at simplifying procedures required to 
capture a unit’s readiness posture via the Unit Status Report (USR). This report consists 
of over thirty pages and is currently handled as depicted in Figure 5.3. The reader should 
note that at least one representative from each battalion, separate battalion and company, 
and subsequent higher commands would be needed to participate in the effort described 
in the figure, totaling at least 42 people. It was this mass of administrative effort, 
information distribution and travel, for face to face coordination, the team was to address. 
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Figure 5.4. Level Zero Diagram ofUSR Procedure 



Similarly, commanders at all levels often require a personnel status report, either 
as part of the USR performed each quarter, or to manage his/her personnel strengths. 
Figure 5.5 depicts the effort a typical battalion exerts in collecting and posting this 
information. It should be remembered that, because the sponsor is a reserve military 
organization, these activities are occurring at various homes throughout the month 
involved. Accordingly, the action required from the team was to identify those items of 
information most often needed and create an interactive environment wherein the 
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company commanders could readily ascertain the information requirements, annotate 
only that information which has changed, and return the information in a standardized 
format for rapid inclusion. 




FORMATS (X5) 



Figure 5. 5. Level Zero Diagram of Personnel Status 



The final requirement identified during the first trip and reported in Appendix A 
involves sharing information about major training activities and events at each layer of 
command. Currently, commands use a variety of scheduling tools such as Microsoft 
Organizer, Calendar Creator Plus, and assorted word processors to record and distribute 
information about planned activities. This information is then physically passed to those 
personnel identified by the creator as needing the information. Anyone outside the 
normal distribution chain who could make use of the information either must request it, 
or is ignorant of its existence. The requirement, then, was to develop a standardized 
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static environment that would be expected, could be used throughout the chain of 
command, and could be easily referenced by anyone with access to the Intranet. 

These base functions are further reviewed in detail in Appendix C, with 
discussion by function for the following areas: 

• Entities affected 

• Number of users 

• Primary owners 

• Frequency of use 

• Mode of use 

• Type and source of information 

• Miscellaneous information 

Appendix B is a trip report, which records the events of a second meeting with the 
project sponsor. There was a dual purpose to this trip. First, the prototype developed 
since the first meeting was demonstrated to determine that the skeleton design and 
functions built to represent the needs identified above were on target. Next, a structured 
walkthrough was to be performed with each of the organization’s key staff members to 
identify any additional requirements. These requirements would ensure that the 
prototype meets the nucleus needs, a must for the Intranet to succeed. 

As to the results of the former, the demonstration to the key sponsor of the 
skeleton design and key functions indicated that these efforts were on the mark. The 
sponsor gave the approval to proceed with development of the Intranet exactly as 
prototyped. While the latter activity identified no new nucleus requirements, a number of 
“nice to have” requirements emerged. Since it was deemed important that the key staff 
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involved in this process support the concept of an Intranet if the scheme were to succeed, 
as many of these functions were incorporated as time allowed. The requirements for 
those functions incorporated are discussed below. 

Overall, it was agreed that the biography template (complete with digital image) 
was viable for the Commanding General, Assistant Commander (Maneuver), Assistant 
Commander (Support) and the Sergeant Major. Subsequent layers of command would 
contain biographies for the Commander, Executive officer and Sergeant Major. 

The officers and non-commissioned officers of the personnel and administration 
section, the G-l , determined that a requirement for a directory of staff officers and senior 
non-commissioned officers with phone numbers and addresses existed. These directories 
are traditionally maintained and distributed in paper format, and are very difficult to keep 
up to date. Often, the paper copy is not present when needed, and reduced copies are 
often carried. 

Another problem often faced by G-l/S-1 is locating and copying the many 
standard forms used by the Army. The need existed for a centralized repository of 
downloadable electronic versions of these standard forms, and the potential existed for 
use of the Army standard form generator, Form Flow by Delrina. 

Finally, the G-l identified the need for a report matrix, which would contain a list 
of required reports, indications of who was responsible for submittal, and when the report 
was due. It was generally agreed that these “suspense” pages would be a usable tool for 
each staff section, and would be added to each section's content. 

The intelligence personnel of the G-2 identified a unique need. These personnel 
are involved in a process of continually updating and distributing an unclassified threat 
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brief for subordinate unit intelligence personnel and commanders. By nature, these 
reports will be out of date before the recipients can obtain and read them. The team’s 
objective was to create a readily updateable vehicle for conveying these reports. 

The G-2 further identified a problem that many staff officers share. As the 
Division Intelligence Officer, Division Logistics Officer, Division Personnel Officer, etc., 
these staff officers represent their occupational skill as the senior member in the 
organization. As such, it is incumbent on them to monitor staffing levels within the 
division for those personnel in their field in order to balance deficiencies and overages 
between units, and to notify the commander and Army manpower agencies when major 
deficiencies are identified. Accordingly, it was requested that the team develop a means 
for these managers to conduct a query and receive data on the present and future 
population of any given Military Occupational Specialty. 

The operations staff in the G-3 had several functions to be added to the Intranet 
prototype. Perhaps the most important of the functions was the event calendar identified 
earlier. The G-3 usually maintains an event calendar showing major training events. A 
related function is provided by the Standard Army Training System Version 4.0. This 
CD delivered product provides both scheduling tools and standard training and training 
requirements reports and forms. It was requested that the team research this tool and 
discern what level of interaction with this system the prototype could achieve. 

Another derivation on an earlier identified need was an action oriented suspense 
page, as opposed to an administrative report suspense page. The Logistics officials in the 
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G-4 also desired an action-oriented page. The team’s task was to develop a template 
page wherein required actions and updates on event planning could be posted for all to 
share. 

Figure 5.6 illustrates a coordinating procedure known among the reserve officers 
as “Dark Night”. The concept behind this procedure is that planning documents for 
upcoming drill weekends are distributed for review and key members from staffs up and 
down the chain of command travel to a central location on the Thursday prior to a drill to 
coordinate required actions and the review plans. These officers then travel back to their 
homes, work Fridays and travel once again to their unit for weekend drill. The reader 
should note that both the cost of distribution of plans and travel for coordination are 
normally absorbed by the individual officer. There is a clear requirement, then, for a 
method of distributing and discussing drill plans before a weekend which lessens the time 
and cost to the officers. 

In addition to the event page described above, the G-4 also identified the 
requirement to provide a viable means for requesting supplies and services in a fashion 
which ensures approval from the logistics shop at the subordinate command. The 
sponsor identified the need to specify procedures for determining requirements and 
ordering supplies by their class of supply (I-X). Further, several local forms used to 
request such services as bus support or convoy permissions have been developed and are 
currently handled in paper format. The Intranet was seen as a good vehicle for 
distribution of these forms and providing a means for submittal of requests. 
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REVIEWED PLANS 




Relations with the organization have also identified the requirement for the team 
to provide recommendations on content quality and control. It is recognized that since 
the Intranet is to reside on government owned equipment and be available to government 
employees, the system content should be in accordance with both societal norms and 
current regulations. A thorough identification of Army and DOD requirements and 
valuable content control measures from civilian organizations is needed. 

As mentioned in Chapter IV, these ongoing relations have also identified the need 
for the team to provide recommendations on potential security directions that the division 
should consider. 
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E. CONCLUSION 



This chapter sought to acquaint the reader with the most plausible of the 
division’s requirements, as determined by the Intranet team’s ability to provide solutions. 
The requirements were broken between the essential design, some priority functions and 
some nice to have additions designed to ensure support by those key staff sections whose 
participation is needed if the Intranet is to succeed. While implementation of the basic 
design, key requirements and nice to have items will be discussed at length in the 
forthcoming chapter on prototype implementation, the last two considerations involving 
recommendations on security measures and content control procedures will not be 
addressed again until Chapter VII. 
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VI. THE PROTOTYPE 



A. INTRODUCTION 

The goal of this chapter is to walk the reader through the prototype development 
process actually followed in creating this Intranet prototype, and explain the design and 
functionality evolution that transpired along the way. 

B. DEVELOPING A WORKING PROTOTYPE 

Following the prototyping process defined in Chapter IV and represented in 
Figure 4.2, the first step in prototype development is a very rapid determination of the 
user’s basic requirements. Chapter V discussed the gathering and definition of these 
initial requirements. The team's goal in developing the “first cut” prototype was to 
provide a very limited, rapidly produced set of Intranet pages incorporating the major 
functions to simultaneously validate and verify the initial direction of the project. The 
below paragraphs describe and exhibit the efforts made in developing this first cut 
prototype. 

The first requirement to be addressed was, by necessity, the basic design of the 
Intranet, the cornerstone of the project as a whole. The primary consideration here was 
that a division viewpoint should be used to guide the design development. The reader 
may remember that Figure 3.1 shows the structure of the 40 th Infantry Division first 
introduced in Chapter III. The average military member is fairly conversant with this 
structure and most activities are controlled using personnel along this chain of command 
in a hierarchical manner. As a consequence, the team believed that this design, which 
followed the organization's structure, would be the most intuitive way for users to 
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navigate the web. Figure 6.1 shows the structure of the Intranet. This “screen shot” 
represents what will be called the left frame. It is this frame which becomes the vehicle 
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Figure 6.1. Left Frame Layout 

for navigating the Intranet via the command structure. Note that only the major 
commands are listed on this page. 

Figure 6.2 shows the structure of the right frame the user encounters upon 
selecting a unit from the left frame. As can be seen by the concentric layering, this frame 
provides the method for navigating at any given level of command. Each level contains 
links to both staff sections and subordinate commands. It is also in this frame that the 
links to the required functions identified in Chapter V will exist. 
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Figure 6.3 provides a view of the initial frames as seen from a browser. 
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Figure 6.3. Opening Screen 

Figure 6.4 demonstrates the change the user would witness to the right frame if 
selecting the G-4 link in Figure 6.3. The reader should note that the functions identified 
for the G-4 in Chapter V are represented as links in the new matrix. It should also be 
noted that the left frame is never changing, providing the user with a means of easily 
moving from one major command to the next, and always returning to the “home page” 
represented by the upper level Division page seen in Figure 6.3. 
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Figure 6.4. G-4 Selected 

Figure 6.5 displays the right frame presented when the user selects the 1 st Brigade 
from the left frame. Attention is directed to the similar structure of the right frame 
between the commands. Even though subordinate units have now appeared in the matrix, 
the overall format remains the same to improve intuitive browsing by the user. Note also 
that the staff sections are represented, but now show the “S” designation vice the “G” 
designation used at the division level. 

Another primary design consideration is the speed with which the system will 
respond. Efforts to ensure a rapid response of the system included simplicity and 
standardization of color, number of page formats and page design. Since the left frame 
never changes, this page is always cached on the user's computer after initial download. 
Similarly, the background for the right frame (at any level of command) is composed of a 
single picture of brown “spray paint” speckles designed to load quickly. There are only 
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Figure 6.5. 1 st Brigade Home Page 



two other backgrounds used in the right frame of the Intranet. Once below the staff level 
at any command, the user encounters a white background with a watermarked U.S. Army 
insignia. Below this level is a white background with a watermarked 40 th Division 
insignia. Again, once downloaded, these pictures are cached, and will quickly return 
upon change of levels. Page design was kept simple, with the same, quick loading 
delimiting lines and standardized artwork throughout all layers of the Intranet. Sounds, 
video streaming and other time and space consuming features were avoided. 

The next requirement addressed was the personnel database. What the team heard 
initially from the project sponsor, in reference to tracking personnel information, was that 
the information provided by the state’s SIDPERS database is outdated and does not 
provide a timely and accurate reflection of the personnel status in the division. Another 
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complaint about the SIDPERS system was the limited access and limited querying 
capability. The scope of the project prevented attempting changes of a large legacy 
system such as the SIDPERS system. Rather, it was our intent to show the division the 
dynamic functionality available which, with further analysis, could set the stage for the 
development of a full-blown web-based internal (within the division) personnel database 
management system. The personnel management system should be developed so that it 
can work in concert with the legacy SIDPERS system and focus on overcoming its 
shortfalls (i.e., no timely data updates, limited access, limited querying capability). 
Ideally, the two systems would interact so that data could be shared. Which personnel 
information fields to track and place in the dynamic database was determined by studying 
a stand-alone database put together by the 240 th Signal Battalion. The developed 
prototype consists of two input forms which contain sixty-eight fields of personnel 
related information. One of the two input forms is pictured in Figure 6.6. 
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Figure 6.6. Data Entry Screen 
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We demonstrated to our sponsor the ability to store and retrieve database records 
using the input screens put together for the initial demonstration. It was agreed that 
further development in this area would focus on the SIDPERS shortfall areas (i.e., query 
capability, accessibility, data timeliness and accuracy, etc.). 

The requirement for a local personnel status reporting form was fully addressed 
before the next meeting. A spreadsheet solution already used by division (See Figure 
6.7) proved to be the answer. Another spreadsheet solution was available from the 240 th 
Signal Battalion. While both solutions were included in the prototype, further 
discussions as to the solution will refer to the division model. This spreadsheet can be 
adapted to work at any level of command. The team took advantage of “working 
together” inherent in using all Microsoft Office compatible tools, and linked the report to 
the G- 1/Personnel page. Once linked and selected by the user, this file will regenerate on 
any computer having Microsoft Excel. For those who do not desire to load Office 
products or other executable suites on their Personal Computers, the webmaster can make 
available downloadable viewers for various products, or direct the user to the company's 
web page on the internet, where viewers are almost universally available for download. 

If the user desires to make changes to the Excel file and return it to the Battalion (via E- 
mail attachment or FTP), an executable version of Excel or Excel compliant spreadsheet 
must be resident on their PC. 
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Figure 6.7. Personnel Master Report Spreadsheet 



This function met with approval as displayed, and no further revision was 
necessary. 

Figure 6.8 provides a view of a basic weekend timeline saved in HTML format 
from Microsoft Schedule Plus. This schedule was prepared as an example of what may 
be done in the field of event scheduling. The reaction to this schedule and the other 
functions discussed above will be the subject of the next section. 
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Weekfof 2/23/97 




Figure 6.8. Microsoft Schedule in HTML 



C. INTERMEDIATE STEPS 

1. Demonstration of the Prototype and User Satisfaction 

As brought out in Chapter V, a structured walkthrough was conducted with both 

the sponsor, and members of the division’s primary staff. This step provided the 
following results: 

• The basic design was considered satisfactory, and the team was requested to 
continue filling out the “skeleton”. 

• The command was very pleased with the concept demonstrated by the Active 
Server Page - Database combination, and desired a continuation along this 
path, providing some further guidance as to desired functions, to include the 
MOS search identified by the G-2. 

• The Personnel Status Report was blessed “as is”, and the team determined to 
spend no more effort on this tool. 
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• The training schedule example served its purpose as a vehicle for generating 
follow-on requirements. While some purposes could be served by the 
daily/hourly format afforded by the Microsoft Schedule Plus format, the more 
universally used Calendar Creator Plus format was desired. The “event box” 
feature allowing a multi-day view of a single event ensured that Calendar 
Creator had become the de facto division standard. 

• At the time of the structured walkthrough, not enough information about the 
Unit Status Reporting procedures had been gathered to include this function in 
the initial prototype. 

2. Gather Follow-on Requirements 

At the second meeting with the project sponsor, the prototype walkthrough was 
repeatedly conducted with each of the senior officers and staff non-commissioned 
officers from each of the sections. As stated in Chapter V, the purpose of this activity 
was to gather additional requirements for follow-on inclusion in the prototype. These 
requirements took shape both in the form of those identified for the basic functions 
above, and also the “nice to have” items which would help increase support of the project 
within the division. The additional liaison with the organization also helped to provide 
more information on and better substantiate the requirements for the USR task. While 
Chapter V has already covered these requirements in adequate detail, the next section will 
describe how the development team met these needs. 

B. ENHANCEMENTS TO THE PROTOTYPE 

The discussion on the revision of the prototype model begins with the interactive 
personnel database. The utility in having an accessible database in a web environment is 
that those authorized access can use it as a decision support tool by way of useful queries. 
Microsoft Access provides the capability to save queries and forms in HTML format. 
Active Server Pages created by Microsoft are HTML pages which are created by the 



73 



Switchboard 




M01ectT^5| 


Last(^Mr®i 




LU 

II 

A 

wmm 


Query 


4/14/97 4:24:04 PM 




Ijfemales 


Query 


4/14/97 3:51:13 PM 




iflaqs 


Query 


4/14/97 4:17:11 PM 




|GT>120 


Query 


4/14/97 4:20:00 PM 




|mos 


Query 


4/14/97 3:44:45 PM 




^nondeplovable 


Query 


4/14/97 4:14:17 PM 




weaponqual 


Query 


4/14/97 7:56:43 PM 




First 


Form 


4/30/97 9:07:42 AM 




1 Second 


Form 


4/30/97 9:08:31 AM 





Figure 6.9. MS Access Switchboard 



server “on the fly” or dynamically. Figure 6.9 depicts an MS Access generated 
switchboard. Access 97 allows you to save forms and queries in HTML format and 
provides a convenient way to access them via switchboard that contains links to the 
desired form or query. Figure 6.10 shows the results of a query for all soldiers in the 
grade greater than (>) or equal to (=) E-7. This HTML results page was dynamically 
generated by the server software and sent to the client browser. An endless number of 
queries can be generated using any number of the 68 data fields and posted to the 
switchboard. As can be seen on the switchboard in Figure 6.9, a Military Occupational 
Specialty (MOS) query was developed in the prototype which allows users to query for a 
particular MOS, a requirement discussed previously. 
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Figure 6.10. Query Response Page 




Figure 6.11. Connection to USR Templates 
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The USR requirement was solved in a manner very similar to the Personnel Status 
Report effort. The 3 1 -page report was found in a format that could be saved as a 
Microsoft Word template and saved in the web as a file. Figure 6.1 1 displays the link 
between the G-3 shop’s web page and the file. When the user selects this link, the file is 
downloaded and can be saved or manipulated, then E-mailed back. Further, once 
downloaded, these files can be viewed and manipulated within a teleconferencing tool 
that will be described in greater detail in the Dark Night paragraph below. By using these 
methods, the 42 plus unit representatives can be spared the time and expense of physical 
file transfer and face to face coordination (represented in Figure 5.4) currently taking 
place each quarter. 
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Figure 6.12. Event Calendar Index Page 
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Figure 6.12 displays the actual sample page created to answer the problem of a 
standardized event calendar. Contact with the Soft Key Corporation, makers of Calendar 
Creator Plus (CCPlus), indicated that no effort was currently being expended toward 
making an HTML version of their product. Since CCPlus was clearly the tool of choice 
among the division’s planners, a method of posting the calendars already being created 
appeared to be the most viable solution. Accordingly, the team created an index based 
web page with the standardized background and look. The user first encounters the top 
of the page, which shows date blocks for that level of command’s calendars. When a 
date is selected, the page advances to that portion with the CCPlus calendar pasted 
directly to that section, as shown in the Figure. Using this template page, units up and 
down the chain of command may now post their training and event planning calendars on 
their unit’s web. These planning tools will then be available for absorption by members 
of the command, and for coordination with higher level and adjacent commands. 

Of the additional functions requested by various staff sections, one of the most 
useful was a directory model that could be used at each level of command to keep up to 
date points of contact. The template represented in Figure 6.13 is also based on an index 
web page design. When a letter is selected, the browser proceeds to that portion of the 
page and the data is presented. Since the data is cross-referenced by name and billet, 
either an individual or all persons in a particular section can be displayed. Moreover, a 
web connection to that person’s E-mail address can be installed. When selected, this 
connection will launch the user’s default mail program, enabling immediate message 
writing capabilities. Additional useful information has been appended to the end of the 
directory. These include a listing of all E-mail account holders and a listing of all unit 
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addresses and duty telephone numbers. This template could easily be used in conjunction 
with a password-protected web structure to provide home addresses, phone numbers and 
“social rosters” often tightly controlled in paper form. If each layer of command were to 
copy and maintain this directory, a very up to date point of contact hierarchy could be 
easily laid out, with links from a central page at the division level to subsequent layers of 
command. 




Figure 6.13. Division Directory Page 
To facilitate use of the directory, the team also decided to add a search engine 

function on the division’s home page. By typing a name, billet or function into the query 
block, all the pages contained within that web will be searched for mention of the 
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requested “term”, and return a matrix of connections which provide links to the pages on 
which the term can be found. 

While it might prove possible to run the Form Flow executable program from the 
network server, running it within the prototype was infeasible. However, the team did 
have some success in dealing with this application. By saving the files for each of the 
forms in the format used by Delrina’s Form Flow, then storing them within the web, a 
link to each form could be made. Like many of the applications identified above, any PC 
with the Form Flow executable file could download and manipulate the files. This setup 
allows the client PC to be as thin as possible, alleviating the need for storing seldom used 
formats, and allowing access even when traveling. 

The next function the team addressed involved the Required Reports page 
identified as essential by the G-l. Figure 6.14 depicts the page developed to handle this 
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Figure 6.14. Portion of G-l Required Report Page 

need. A table generator was used to create a matrix with required reports along one axis 
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and dates along the other. Codes were used to indicate who was responsible for report 
submittal. It should be pointed out that if the report is in a standardized local format, a 
link to that form could easily be established, using the block containing the report name 
as the launch point on the page. Further, if the need exists to archive any given report, an 
interactive database similar to the personnel database could be set up to retrieve data from 
the users and store it appropriately. As mentioned in Chapter V, these suspense pages 
were provided in each of the staff section’s webs, and a template provided for use at 
lower levels. 

The solution suggested to tackle the G-2’s continuous need for publishing 
unclassified threat and country briefs was the corporate newsletter. As seen in Figure 




Figure 6.15. Intelligence Newsletter 
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6.15, a G-2 newsletter was created and saved in HTML format. Using an HTML editor, 
the G-2 authorized representative can easily update text, photos and links to other sites 
such as maps, better addressing the perishability of information issues, and reducing time 
and dollar costs associated with updating and redistribution. Similar sites could be 
established for fictional threats during staff planning exercises. Password protected 
versions may prove to be an acceptable means of communicating higher classification 
briefs. 

Like the Form Flow forms generator, the Standard Army Training System (SATS) 
executable could not be run from within the Web. However, the program CD contained 
the system’s numerous required report formats saved as Microsoft Word templates. By 
saving these to the web and creating links for the reports, the SATS program could be 
bypassed and the user could open these formats directly with Word, then manipulate and 
submit them electronically. 

One of the functions requested by the G-3 is expected to become a widely 
accepted change in current procedures. This function is the Dark Night event-planning 
page. As discussed in Chapter V, a large number of officers from all levels of command 
are required to expend massive time and energy conducting coordination prior to any drill 
period. The commander’s letter, depicted in Figure 6.16, contains guidance and planning 
documents generated by the key staff and commander of a unit. The individual officer 
within a unit can then browse the pages prior to coordination. Next, the commander and 
his staff may coordinate either at will or at a pre-designated time using teleconferencing 
tools. 
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Figure 6.16. Sample Dark Night Page 
The tool designed to be run with FrontPage and IIS is a free download program 
from Microsoft, and is available at the microsoft.com Internet site. Figure 6.17 is a 
screen shot depicting this tool in use. In addition to standard chat and whiteboard 
functions, this tool allows document sharing, document collaboration (i.e., shared 
revising), audio and video. Once a document is tagged by a conference, the document 
may be revised by anyone assuming control, using the executable from the PC of the 
person who posted it. The audio is very usable for discussing changes as they are made. 
The video could be useful, but will slow response time of other features. As mentioned 
above, this tool is a good alternative to traveling for coordination purposes, and can be 
used for other event planning and collaboration needs. Additionally, the tool should 
prove very beneficial in USR report validation/verification, relieving the unit 
representative from having to travel. 
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Figure 6.17. NetMeeting 



Similar event planning pages were created for the G-4, which should prove useful 
whether used in conjunction with NetMeeting, or used solely as an information tool. 



83 









Since both the G-3 and G-4 are heavily involved in event planning and control, 
the standard report matrix used throughout the rest of the staff was modified to include 
action items. Figure 6. 1 8 provides an example of this type of suspense page. Again, 
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Figure 6.18. Report/Action Suspense Page 



codes may be used to provide information beyond the action item, and the suspense dates. 
Room for a legend is provided at the bottom of the web page. 
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Figure 6. 19 presents the G-4 homepage. The reader’s attention is drawn to the 
table in the center of the page. While suspense and event planning pages have already 
been discussed, the table also provides the user the opportunity to link to pages 
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Figure 6.19. G-4 Home Page 

concerning various classes of supply. These pages can contain information about how to 
order the supplies, who will be charged, and planning considerations. The other major 
link from the table is to the support requests page. On this page, the user will find a list 
of links to individual support request forms that have been in local use for some time. 
The prototype team converted these forms into Microsoft Word templates and stored 
them in the G-4 folder of the Intranet. Figure 6.20 displays how selecting one of these 
forms causes Word to be launched on the user's PC, immediately opening the required 
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form for use. This form can then be E-mailed back to the G-4 for action. While an 
interactive database solution could also have been applied, the G-4 felt the E-mail step 
provided them the means to authenticate that the person making the request indeed had 
the power to do so, as the return address would identify them as a key billet holder. 




Figure 6.20. Convoy Request Opened Within Browser 

Lastly, the overall design was finalized. Templates were made of home pages, 
biographies, suspense pages, etc. These pages were then duplicated at the division level 
as appropriate and a link to these templates was created on the left frame so that 
subordinate units could gain access as they filled out the skeleton structure already 
provided them. 
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E. OPERATIONAL PROTOTYPE 



Once the above action was complete, a second structured walkthrough was 
conducted and the prototype was accepted. As discussed in Chapter IV, this action 
marked the passing from the initial prototype to the operating prototype phase of the 
prototype life cycle. Chapter IV also introduced the concept that, unlike traditional 
software development, Intranet content is constantly evolving. It can be seen, therefore, 
that this phase represents more than a transition to an operation phase, but instead 
represents a transition from the prototype development process to the end-user 
development process. 

F. CONCLUSION 

The prototype development process defined in Figure 4.2 was followed in 
developing this Intranet. This method was used both because of the rapid time frame the 
sponsor desired to work within, and because of the somewhat ill defined requirements. In 
this instance, the ability to provide a structured walkthrough not only ensured an adequate 
design, but also really helped to identify the potential the Intranet technology could 
provide for this unit. The goal of this chapter was to walk the reader through the 
prototype development process actually followed in creating this Intranet prototype and 
explain the design and functionality evolution that transpired along the way. 
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Vn. RECOMMENDATIONS FOR INTRANET OPERATIONS 



A. INTRODUCTION 

The planning and consideration involved in developing and implementing an 
Intranet is extensive. With no prior experience in developing or implementing Intranets, 
our research in this area focused on those who have had experience and have shared their 
lessons learned. This chapter contains two sections. The first section is on Intranet 
policy, followed by a lessons learned section, which documents and references lessons 
learned for those organizations that have successfully implemented Intranets. This 
section includes the author's recommendations, which, given the division's current unique 
situation, provides the division with next step recommendations for implementing their 
Intranet. 

B. INTRANET POLICY 

In order to maintain a disciplined Intranet environment it is absolutely essential 
the division establish an Intranet policy that will guide and control the division's Intranet 
efforts. At the time of this writing the Army has not published a policy concerning the 
management and control of Army Intranets. Appendix 3 contains a 30 October, 1996 
letter released by LTG Otto J. Guenther, who is the Army's Director of Information 
System for Command, Control, Communications, and Computers (DISC4), entitled 
Guidance for the Management of Army Web sites. Although it does not specifically 
mention Intranets, much of the guidance set forth in the document is also relevant in an 
Intranet environment. This document also mentions that a final policy is being 
coordinated. 
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1. Security 

According to Stephen Cobb, director of special projects at the National Computer 
Security Association (NCSA), "If you are not ready to write and enforce Web specific 
security policies, then you are not ready to roll out an Intranet" [7.1]. A formal policy 
shows that an organization has thought ahead and considered the security issues 
including, how to combat threats to security and actions to take if security defenses are 
breached. 

Intranet Security can be broken down into two primary areas, content security and 
access security. Content security concerns the classification level of the information 
which will be published on the Intranet. Access security is allowing only authorized 
users (those with a valid login) to be able to access the content on your Intranet. Once on 
the network, access control can be used to allow only those given permission to access 
certain pages on the Intranet. 

2. Content 

What information will be required to be posted on the Intranet? Will there be a 
standard look (i.e., division symbol on each page, etc.) for each published web page? 
What will be the size limitation for each web page produced (larger files require longer 
download times)? What will be the content security classification limitation for web 
documents posted on the Intranet? Who will be responsible for production of web pages? 
Who will be given the authorization to identify what will and will not be posted on the 
Intranet? Who will be ultimately responsible for the content on the Intranet? These are 
just a few of the many questions, which will have to be addressed in the content portion 
of the policy document. In order to enforce established guidance and policy in this area, 
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it is imperative the division also has in place a corresponding mechanism to ensure that 
members of the division adhere to the written policy. Some other areas, which fall under 
the content heading, include maintenance and web page posting. Consideration is going 
to have to be given to how often web pages will be reviewed, updated, and removed. 
What about the posting of web pages? Will this responsibility rest totally with the 
division's webmaster? 

3. Applications 

In-line with the RCAS fielding, the division has established Microsoft Office Pro 
as the standard office automation suite. The tools operate in a somewhat seamless 
Windows 95 environment where files are easily shared amongst the different office pro 
application programs. The Office Pro 97 version gives the user the ability to save 
documents in HTML format, which makes the publication and posting of web material 
very simple. The client/server environment was explained in Chapter II. Recall that 
when the client's browser downloads a specific file type (i.e., .xls file extension, 
(Microsoft Excel)), in order to view the file on the client machine the application must be 
installed as a resident program on the client. Policy provisions need to be made as to 
which file types will be made available for download on the Intranet. The use of Delrina 
FormFlo is widespread throughout the Army and the 40 th Division. A few forms with the 
.frz extension were included in the prototype to demonstrate the ease and usefulness of 
the application. The electronic use and processing of Delrina Forms will greatly improve 
the efficiency in which administrative forms are processed. 



91 



With the limited amount of application programs available, consideration needs to 
be given to the administrators who will be responsible for the production and processing 
of administrative information. 

4. Servers 

It is imperative that those responsible in the division for information systems 
planning understand the short term plans and long term vision of the California National 
Guard and the RCAS system. In addition, they must understand the DOD IT twenty-one 
initiatives which includes the Army's Technical Architecture and the information 
technology standards that are being established. Being able to understand the vision of 
the state and National Guard bureau and following the standards being established in the 
RCAS and the ATA will allow the division to better posture itself for receipt of the 
program-funded RCAS hardware and software components. The state anticipates it will 
begin receiving RCAS funding support in the 2QTR of FY98. 

Recall from the client/server model presented in Chapter II that the web materials 
(i.e., HTML pages, files of different types, etc.) resides on the server. The division 
Intranet resides on one machine currently. Will maintaining one server at a single 
location be practical for the division in the future as the Intranet grows? How many 
servers are practical, affordable, and reasonable? Does it make sense to have one for 
every brigade level element? These are the types of questions that the Division 
Information Management Advisory Council (DIMAC) will eventually have to address. 
The division has standardized the division's network operating system as Microsoft NT 
4.0. NT 4.0 comes bundled with Internet Information Server, which is Microsoft’s web 
server software. 
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NT Server is one of the compatible operating systems that have been identified in 
the Army's Technical Architecture and will be the primary server operating system for 
the RCAS system. 

Eventually the division will want to decentralize the content development process. 
Prior to the decentralization, consideration will have to be given to training qualified 
personnel (i.e., subordinate unit webmasters) who will be able to prepare and post unit 
content and coordinate with the division's webmaster. 

5. Client 

Because of the no-cost download available, the Division Information 
Management Advisory Council (DIMAC) has decided on Microsoft's Internet Explorer 
(IE) as the default browser for users on the Division's Intranet. The server-based web 
content is currently being developed with the assumption that most of the users will be 
using the freely available IE. Although other browser types can be used, web page 
appearance will not always be guaranteed unless using IE. Some of the interactive 
content (i.e., ActiveX, plug-ins, etc.) requires the use of Internet Explorer. 

Because access will be limited to the Intranet initially, acceptable usage should 
not be an issue. When the capability to access the Internet arrives at the division (see 
RCAS architecture), the division will have to implement policy that indicates what kind 
of usage is acceptable (i.e., authorized surfing). If the division feels that enforcing policy 
by tracking visited web sites is a necessity, there are network management tools for sale 
that allow network administrators the ability to track network client usage of the Internet. 

Training is another issue which will have to be addressed by the DIMAC. 
Although learning and using a browser are easy things to do, consideration still needs to 
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be given to those personnel in the division who have never been exposed to browsers and 
the internet. An approach would be to coordinate the development of a New Equipment 
Training Team (NETT) which could travel to the different units within the division to 
conduct web browser/intranet training. A less expensive method would be to take a 
"Train the trainer" approach. Training packages could be developed and posted on the 
Intranet. This would be followed by an identification and recruitment of unit level 
personnel who are computer proficient. The training packages would be thorough 
enough to provide the trainers with an outline of what material should be covered, along 
with ideas and teaching techniques that will enforce learning. 

C. LESSONS LEARNED AND RECOMMENDATIONS 

Although certainly not all encompassing, this section provides the reader with 
some of the lessons learned by other organizations in the area of Intranet development 
and operations. The intent of this section is to not only provide the customer with lessons 
learned, but also to discuss the lessons learned in the context of the division’s current 
situation. The following is a list of eight recommended steps the division should follow 
in order to achieve success in the early stages of bringing up the Intranet. These steps are 
not listed in any particular order and are a compilation of the ideas extracted from various 
Intranet readings. [7.2, 7.3, 7.4, 7.5, 7.6] 

1. Responsibility 

What may seem obvious in a military environment is not necessarily so. In order 
for the Intranet development to move forward and progress, responsibility and 
accountability have to be assigned. Someone in the organization will ultimately have to 
be the decision-maker when it comes to decisions concerning the Intranet. This person is 
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the G-6, responsible for information technology management in the division. The G-6's 
officer representative for automation affairs in the division is the Division Automation 
Officer (DAMO). The DAMO should be a person who not only has a good understanding 
of the technology, but, most importantly, has a clear understanding of the division's goals, 
and is politically up to the task of working with differing personalities and conflicting 
ideas.[7.2] 

The division G-6 should consider establishing a position for the division's 
webmaster. This position would be a full time job best held by a technically astute senior 
NCO. This NCO would be responsible for the day to day operations of the Intranet. 
Written policy, which will be addressed in one of the following steps, will have to 
address the full scope of the duties and responsibilities associated with being the 
division's webmaster. It will be extremely important for the division's webmaster to 
understand the vision and intent of the G-6. The division webmaster will play an integral 
role in developing the division's policy for Intranet operations as a member of the 
Division's Information Management Advisory Group (DIMAC). 

2. Strategic Level Planning 

With the Reserve Component Automation System (RCAS) being implemented 
throughout the division, it is imperative the DIMAC understand the state's long-range 
strategic level automation plans. According to the automation representatives at the 
state's National Guard headquarters in Sacramento, federal funding for the RCAS 
program is due in the 2 nd quarter of FY98. All initiatives being taken now by the 
division, including the further development and implementation of the Intranet, should be 
in-line with the state-level vision. This includes those efforts, now ongoing, to posture 
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the division to receive and integrate the RCAS system into the state's information 
infrastructure. All the tasks associated with the RCAS posturing, Intranet 
implementation/operations, and RCAS implementation should be identified. The 
necessary resources needed to accomplish these tasks also need to be identified. A long- 
range calendar should be incorporated in the Strategic Plan, which depicts the events 
associated with the state and division-level vision of what is being planned. 

Eventually, the division headquarters (i.e., G-6, DAMO, and division webmaster) 
is going to want to decentralize Intranet control. This means that tasks such as 
production and posting of web content and the proliferation and control of subordinate 
unit web servers will eventually be given to Brigade and below level elements. The 
impact of the natural decentralization process needs to be considered now so planning for 
the decentralization can take place. Some of the impact areas which need to be 
considered in a short-term strategic plan include; identification of pre-intranet and post- 
Intranet processes and training for subordinate unit webmasters/system administrators. 

3. Intranet Advisory Team [8.3] 

The DIMAC is the logical choice to serve as the nucleus for the Intranet advisory 
team. A user representative from every part of the division, including each echelon from 
company level up through and including a representative from the state headquarters in 
Sacramento, needs to be included as a member of this team. It is critical that the Intranet 
is serves the needs of the user. In order to insure this, the team needs to consist of a 
representative user base and those with decision authority to enact proposals presented by 
the team. Initially, the team will have the lone division webmaster. As the Intranet 
grows, the division will need to decentralize control. Eventually, each Brigade size 
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element and ultimately each battalion size element will have their own webmaster, and 
they should be added to the team. Before the decentralization can take place, a 
disciplined strategic approach addressing the Intranet's development and implementation 
will have to be developed and disseminated by the DIMAC. 

4. Intranet Policy 

Section B of this chapter discusses the importance of written policy covering 
Intranet operations. As mentioned previously, the Army currently has a three-page 
interim policy letter signed by the DISC4 that discusses Internet web policy. A more 
formal policy is forthcoming. There are a number of corporations who have put together 
policy regarding Intranet operations. Unfortunately, they are not as restrictive and 
disciplined as we believe a military Intranet policy should be. The areas discussed in 
section B should be researched and discussed thoroughly, with decisions made in these 
areas published. The military is known for its numerous policy letters, which cover a 
wide range of operational activities and processes. The development and implementation 
of an Intranet is no different. The fact that written policy must be developed for the 
division's new Intranet can not be overstated. 

5. Funding 

Although web technology is relatively inexpensive, the costs associated with its 
operation (i.e., servers, authoring tools, client workstations, connectivity, application 
software, operating system software, etc.) have got to be identified. What resources is the 
division responsible for? What funding will the state provide for this initiative? What 
kind of resources will be provided by the federally funded RCAS implementation? These 
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and questions like them need to be answered in order to adequately plan for and prepare 
for Intranet resourcing. 

6. "Open" Technical Solutions 

Those responsible for the hardware and software solutions associated with 
improving the Intranet's current capabilities should consult the automation professionals 
at the state headquarters to insure any proposed solutions are in-line and compatible with 
what future plans call for. According to the state headquarters, the RCAS Program 
Management Office will begin fielding the system in California. 

7. Patience 

The division needs to look at the Intranet implementation and operations from a 
"crawl, walk, run" perspective. The obvious analogy here is the different stages of a 
child's mobility development (i.e., first a child learns how to crawl, then to walk, then to 
run). 

a. Crawl 

Upon our delivery on 2 May, 1997, the division decided to 
immediately put the prototype on-line. Having just received the operational prototype, the 
division is in the "crawl" stage and will have to spend some time finishing the initial 
development. The prototype contains both static and dynamic (i.e., data entry pages 
working with a back end database) pages. The static pages that were created contain 
some worthwhile information, which, of course, will have to be periodically updated. 

The dynamic pages, specifically the soldier data entry forms using the Open Data Base 
Connectivity (ODBC) standard to store, retrieve, and query records in a web 
environment, were developed to show what functionality is available. The team 
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recommends the division continue to maintain the static information but disable the 
ODBC portions of the web site until the DIMAC can conduct a study to identify what 
data entry, retrieval, and query systems will be developed or incorporated into the 
Intranet. Before the division starts using the Intranet for storing and retrieving vital data, 
the security aspects of the system will have to be addressed in detail. What the division 
does not want is to put itself in a position with the Intranet where sensitive data (i.e., 
personnel information, etc.) could be accessed without authorization, compromised, or 
corrupted. Each case where there is a desire to use the ODBC functionality and 
incorporate data storage and retrieval will have to be looked at on an individual basis. 
Disciplined policy and procedures will have to be enacted which discuss access security, 
storage, back-ups, data recovery, etc. What current database information in the division 
can be ported over to the Intranet to make this data readily available throughout the 
division? Is this kind of thinking in line with what the state and the RC AS system will 
provide the division? Is it worth the time and resources now to look at the legacy data 
storage and retrieval systems and how feasible would it be to port that data over to the 
Intranet? Is the new RCAS system going to contain web enabled applications, which will 
provide this functionality? These and many other similar questions will have to be 
studied and addressed by the DIMAC before databases are incorporated into the Intranet. 
During the "crawl" stage, the division should be promoting and selling the usefulness of 
the Intranet. In order to make it useful, the information must be timely and informative. 
Current division news, unit news, training schedules, division calendars, downloadable 
forms, briefings, spreadsheets, etc. are just some of the static information the division can 
be providing its users. Marketing the Intranet at this stage is very important to eventual 
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success. The word has to be put out to all soldiers in the division that this service is 
available. Instructions should accompany the division-wide announcement on how 
individuals can obtain accounts. All members of the division should consider the Intranet 
"their" Intranet and their primary source of division-wide information. 

b. Walk 

With the Intranet on-line and the division wanting the utility of the 
Intranet to increase, the G-6, the DAMO, and the DIMAC certainly have their work cut 
out. One of the first concerns that will have to be addressed is the traffic load dialing into 
the division's modem bank to gain access to the Intranet. The division currently has only 
ten 1-800 lines and approximately 250 authorized users with assigned logins and this 
number is growing. It is just a matter of time before the 10 lines will reach a point of 
saturation and all a user will hear when he dials in to the division's modem bank is a busy 
signal, which can lead to discouragement rather quickly and cause people to discredit the 
Intranet. A modem ratio is the number of registered users to the total number of modems 
in the modem bank. Internet Service Providers (ISP) know it is time to add more phone 
lines/modems when they receive complaints about busy signals. To many U.S. providers, 
the modem ratio is proprietary information they do not wish to share. Those touting a no 
busy signal guarantee usually listed figures ranging from 10:1 to 15:1. The first case 
represents 1 0 registered users to every 1 modem in the modem bank. It can be seen that 
with 250 registered users and only 10 available phone line/modems, the divisions modem 
ratio is already at 25:1 . The DIMAC should consider when and how they would expand 
the current 10 line/modem capability. This is an area which the division will have to keep 
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an eye on very closely in order to provide the best possible service to Intranet users and 
promote Intranet use. 

Education and training are other areas the DIMAC will have to 
address. Deciding who will train, how, and what they will train are probably the biggest 
questions that need to be wrestled with in the short term. 

Also, understanding the state's long term plan for information 
operations (i.e., RCAS, use of legacy systems, data usage, etc.) is critical for the DIMAC. 
Before any Intranet expansion occurs (i.e., the purchase of additional servers, 
applications, modems, phone lines, etc.), the division should draft proposals to the state 
national guard bureau to ensure that the proposed Intranet expansion is in-line with the 
state's long term information operations vision. 

Dynamic web capabilities offer a powerful tool to the division. 

The ability to enter, retrieve, and query information from a database gives the division a 
decision support capability. Information can be put literally at the fingertips of decision- 
makers authorized to access and query databases for the specific data they are looking 
for. Databases of different types are currently maintained such areas as personnel, 
security, operations, and logistics. Recommend that the DIMAC prioritize the areas 
which would benefit the most by the development and implementation of a web based 
dynamic environment where records can be queried, added to, updated, and deleted from 
dedicated databases. As mentioned previously, the DIMAC will have to scrutinize each 
dynamic area developed in order to ensure the safeguard of sensitive data. Once 
developed and approved for implementation into the Intranet, only one dynamic area at a 
time should be implemented. It is recommended that a simple area be developed initially. 
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Redundancy and fault tolerance need to be built into the implementation plan as a 
safeguard measure. 

c. Run 

The division is going to want to decentralize the Intranet. Currently, the 
division's Intranet is operating from one server machine with a couple of soldiers playing 
the part of interim webmasters. Eventually, the Brigades and possibly the battalions will 
want to maintain their own web servers. Given authorization, brigade and battalion level 
webmasters can update information on the lone division server. This process, however, 
can be slow and cumbersome and opens up the division server to unnecessary and 
potentially dangerous access. With the growth of the Intranet, entity sites (i.e., brigade 
and battalions) are easier to maintain with their own resident server. Given their own 
server, webmasters at the brigade and battalion levels will better be able to manage their 
own sites. 

In order to decentralize the Intranet, the division is going to have to 
provide its subordinate brigades with the necessary resources (i.e., server, web 
development tools, training for webmasters, etc.). 

The addition of dynamic areas will continue in the run phase. 

8. Intranet Promotion [7.4] 

In order for the Intranet to be successful, it has to be valued as useful by its users. 
If content is not kept up to date, users will seek other, more reliable forms of information. 
If the Intranet is providing useful information to the division's users, it should be 
promoted from the top. The Commanding General, the Assistant Division Commanders, 
the Division Sergeant Major, the Chief of Staff and the rest of the leadership in the 
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division should play an active role in promoting the use and gradual development and 
improvement of the Intranet. 

D. CONCLUSION 

The division Intranet is new and the information operations associated with the 
Intranet are new as well. Information technology has changed the way we work and 
unless the division embraces the Intranet and addresses the difficulties associated with 
“change” in the work place, the Intranet runs the risk of being discredited or, even worse, 
dying an early death. This chapter discussed Intranet policy and lessons learned and 
hopefully has given the division some ideas on how to successfully implement their 
Intranet. 
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APPENDIX A. TRIP REPORT 1 



Trip Report -Visit to California National Guard 40 th Division Headquarters - 

Cypress California - 19 Dec. 1996 

We met with LTC Rod Barham, the 240 th Signal Battalion Commander for the 
40 th Infantry Division (Mechanized) around 10:00 AM, 19 Dec., at the 40 th Division 
Headquarters located in Cypress California. LTC Barham is the Division Automation 
Officer (DAMO) responsible for the operation and maintenance of all automation 
equipment within the division. 

MAJ Heckroth and I put together a briefing to guide us through our initial 
meeting with LTC Barham. Our intent was to follow the content of our briefing, which 
includes our project’s scope, goals, and objectives. The briefing concludes with a student 
checklist that we put together to insure we had the information we needed for the next 
phase of our project. 

LTC Barham also prepared a briefing that gave us an initiation into the 
automation situation within the division. In order to get better acquainted, we shared our 
military experience backgrounds with LTC Barham and he gave us a brief background on 
his military service experience. 

LTC Barham spent eight years in the Pentagon at the National Guard Bureau. His 
position at the Bureau was as an Information Systems Manager/Developer. He later spent 
some time as an automation professional at the Program Executive Office (PEO) for 
Standardized Army Management Information Systems (STAMIS). LTC Barham said he 
was very familiar with the now defunct Reserve Component Automation System 
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(RCAS). He said the 1 .5 billion dollar program, which ran on a UNIX platform in a 
client server environment, was a multilevel security system that was proprietary in nature, 
very cumbersome and not an intuitive system for new users. The system, which was to 
improve readiness by providing digital connectivity to geographically dispersed National 
Guard units, was scrapped only twelve months ago after an outlay of nearly 2 billion 
dollars. 

The California National Guard was the first unit to field the “old” RCAS system. 
LTC Barham informed us that they (California) would be the last to field the “new” 
RCAS system because of their high priority in the initial fielding. The California 
National Guard is not due to receive their “new” RCAS system until the year 2002. 

LTC Barham, as the Divison’s senior signal officer and automation officer, was 
tasked to come up with an interim system that would provide the division with a digital 
messaging capability with connectivity to all the division’s subordinate elements. In 
addition to a digital messaging capability, the division specified a general requirement of 
having the capability to share data. LTC Barham’s briefing was the same briefing he had 
given to the division’s Chief of Staff and specified his short, medium, and long term 
objectives for the division in the area of automation. 

He mentioned that his number one short-term objective was to give the division 
its own electronic mail (e-mail) capability. At present, soldiers within the division that 
want to conduct National Guard business (i.e., coordination, information dissemination, 
control, etc.) using electronic mail, do it at their own expense (using a local or national 
Internet Service Provider (ISP) mail server). 



106 



LTC Barham is in the process of setting up what he is calling the Division 
Bulletin Board Service (BBS). Following our morning meeting with LTC Barham, we 
met with SSG Gregory Holmes, an NCO from the Division Material Management 
Center’s (DMMC) Logistics Automation Service Support Office (LASSO), who has 
volunteered his services in setting up the Division’s initial BBS/email capability. 

Our meeting with LTC Barham lasted nearly three hours. Our discussion covered 
a wide area of topics. The following areas of discussion are worthy of further mention: 

• User Survey - We showed him an example of a survey that could be 
distributed throughout the division to collect information with regard to user's 
wants and needs. He was extremely interested in possibly modifying the 
questionnaire and distributing it throughout the division in order to “check the 
pulse” of the division. MAJ Heckroth and MAJ Olson thought this would be 
a good idea. LTC Barham has “got the ball” on the user survey. 

• “As-Is” System - LTC Barham was interested in coming up with an “as-is” 
IDEF model similar to the Data Flow Diagrams (DFDs) we put together for 
our IS4200 projects. The “as-is” system would depict garrison information 
flow within the division. 

• Operational Concept - The new “BBS” system the division is bringing on- 
line will need to be maintained (i.e., system administered to add, update, and 
delete users). When the proposed Webserver is brought on-line, policy and 
guidance (i.e., an SOP) is going to have to be provided to website content 
providers in order to insure that only standard, disciplined, and useful content 
reflecting the pride of the Division is allowed to be published. All meeting 
participants felt this was a critical component in order to maintain discipline 
and control of the internal website. 

• Current Vision - LTC Barham’s short-term vision is bringing up his “BBS” 
as soon as possible and giving each HQs element, from division through 
company level, an email account. In addition, each primary division staff 
element would be given an email account. According to SSG Holmes, the 
initial BBS will consist of a standard telephone line, which terminates into a 
ring of eight modems. The “BBS” hardware platform is a 166MHZ Pentium 
Gateway Computer. The “BBS” server software is called TSX-Online. TSX 
is a stand-alone operating system, which also has Internet Service Provider 
(ISP) software functionality, which provides the Divsion’s dial-in users with 
a gateway to its mail server (a TSX utility) and web server (Internet 



107 



Information Server IIS, a Microsoft product). This product is to be used as a 
gateway, with a parallel machine(s) running applications in an NT 
environment. 

• Key Question - One of the key questions that was discussed with Barham 
and Holmes is connectivity. If each HQs element, from division down to 
company level, plus each primary staffer at Division is given an email account 
and each of these mentioned entities checks their mail three times a day, is 
eight modems enough to provide quality service (no busy signals when ISP is 
called to download mail)? There is nothing more frustrating than trying to 
gain access to a dial-in host computer and receiving a busy signal. Physical 
connectivity was also an issue of discussion. According to Barham and 
Holmes, the location of the initial BBS will be established at the Division 
Support Command’s (DISCOM) Logistical Automation System Support 
Office (LASSO) located at 3700 East Spring Street, Long Beach, CA. Those 
Division elements that are co-located with the Division LASSO will have 
direct connectivity to the mailserver and Webserver via local area network. 
Others will have to dial-in to the server or have a dedicated line to the 
LASSOs location. The concerns over traffic volume are magnified with the 
addition of the Webserver to the network, (users stay connected while 
“surfing” vice mail upload/download then dropping connection). Discussion 
leaned toward a traffic volume study that would give the division an 
indication of the number of dial-in modems and direct connect lines they 
would need to provide quality service to its customers. 

• Administrative Forms - A separate problem, but one LTC Barham would 
like to address, is the idea of getting frequently used administrative forms on- 
line in a distributed environment so they can be accessed by division 
personnel. He mentioned programs (ProForms and Forms Engines) that are 
currently used in the Army for electronic preparation and transmission of 
admin forms. 

• Information Modernization Plan - LTC Barham is currently writing the 
40 th Division’s Information Modernization Plan. He gave us a copy of the 
National Guard’s 1995 Modernization Plan he published while an Information 
Officer at the Pentagon. 

• Prototype Discussion - In an attempt to scope our project prototype, we 
asked LTC Barham for a vision of what he considered potential areas for 
initial development of both static and dynamic web pages. He said that there 
are three primary critical information areas that we could incorporate in a web 
prototype. They are readiness, USR reporting, and training schedules. In 
reference to training schedules, LTC Barham mentioned that there is an active 
Army training scheduler currently in use. He told us that he would try to get 
some additional information on the program. We told LTC Barham and SSG 



108 



Holmes that we would pursue the design and development of a dynamic 
prototype in this area. We also agreed to come up with a group of static pages 
that would provide a hierarchical shell, beginning with a division homepage, 
with links to each division staff element and each of the Brigades and separate 
Battalions (i.e., Air Defense, Signal, Engineers, etc.). 

• Student Information Requirements - Information LTC Barham agreed to 
provide students: 

• Division Organization Chart with locations of units down to the company 
level 

• Executive Summary of “old” and “new” RCAS systems 

• Information on how the Guard does business in the three critical information 
areas: readiness, USR reporting, and training schedules. In order to develop 
databases and dynamic web pages that will allow a user to input, update, and 
query information, the developers will need all the forms (which contain 
database fields information) that are currently used in reporting and 
processing information in these areas. 

• Results from previous survey and decision whether to go ahead with new 
unit’s requirements survey 

• As much “As-Is” system information that you can possibly get your hands on. 
This is critical in order to put together a quality “As-Is” IDEF model. 

• Public Affairs Opportunities - LTC Barham mentioned that he wanted to 
capitalize on the public affairs opportunities that will present themselves in 
this project. The students agreed they would participate to whatever degree 
the LTC felt was appropriate. 

• Ground Rules - LTC Barham said the only ground rule he has is that we let 
him review any published documents for suitable National Guard content. 
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APPENDIX B. TRIP REPORT 2 



Visit to California National Guard 40 th Division Headquarters- Cypress, California- 
28 Feb 1997 

This is the second in a series of trip reports. We linked up with LTC Scott, the 
Division G-6/Garrision Commander, at around 08:15. The NPS thesis team of MAJ Tom 
Heckroth, USMC and MAJ Tom Olson, USA had made prior coordination with LTC 
Scott to meet with representatives from each of the G-shops to give them an Intranet 
demonstration and to gather requirements. We had the pleasure of meeting the Division's 
Chief of Staff, Colonel Combs, and the Commanding General for the 40 th Division, 
Brigadier General Edmund C. Zysk before the day's meetings began. 

During our discussions with Colonel Combs, we discussed our intent to recruit 
two more thesis students from NPS that would follow-on and continue to build the 
Division's Intranet. An excellent opportunity exists to build a habitual relationship 
between the systems management department at NPS and the 40th Division, which 
comprises 80% of the California National Guard. We felt it was a good time to bring up 
the funding issue. MAJ Heckroth and I personally funded the two-day trip to Cypress in 
December 1996. We did receive funding from NPS for this trip. Future trips will have to 
be personally funded by the students unless a sponsor steps forward to help defer costs. 
There are other areas where financial support is critical in order for NPS to continue to 
support the Intranet system development. One of these areas is equipment support. The 
development team is currently using one machine that is on loan and could be taken from 
the team on a moment's notice. The team is asking for the funding to purchase two 
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200MHZ Pentium pro systems that will serve as their development platforms. In addition, 
the team will need two copies of Microsoft Windows NT 4.0. The new machines will 
greatly increase the productivity of the development team. The job of recruiting and 
securing follow-on students will also be made easier if prospective thesis students know 
they have guaranteed production resources to help them complete their thesis. We feel 
that without adequate resource support in the future, our production capabilities and 
development productivity will be severely degraded. We look forward to further 
discussions with the division concerning the necessary resource funding. 

We linked up with our sponsor, LTC Rod Barham, Commander of the 240th 
Signal Battalion, at around 08:45. We retired to the Division's conference room to brief 
our sponsor on what we had accomplished since our last meeting on 19 December 1996. 

Our intent for this trip was to get back together with our sponsor (customer) to 
make sure the work we had done was in line with his expectations and vision and also to 
collect further guidance and requirements. 

We discussed with LTC Barham the intent of our visit and set up our notebook 
computer to give LTC Barham a demonstration of the work we have done since 
December. The team told LTC Barham how we felt we had lost about thirty days learning 
the development tools (Microsoft Internet Information Server (IIS 3.0), Microsoft 
FrontPage, and Microsoft NT Server) the division has established as their standard tools. 
Back in December, the team opted to learn and use the tools the division was using. We 
decided that if the division wants to keep and implement the student's prototype at the 
end of the project, they could port the work over to a system using the same tools, thus 
eliminating any compatibility problems. 
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As mentioned earlier, advance coordination was made by the team to meet with 
each of the division headquarters G sections to demonstrate our work to date and discuss 
with each section their potential web content. The intent was to explain the purpose of the 
Division's Intranet, give the demo, and discuss requirements, wants, and needs. 

LTC Barham and MAJ Willand, the headquarters Commandant, received the first 
of five demos we gave throughout the day. MAJ Willand, who is also an automator and 
does a lot of briefing preparation and graphic design work for the division headquarters 
(copy of division's 80th Anniversary program enclosed for thesis advisor Suresh Sridar) 
lent us an external monitor for the day's demos. MAJ Willand told the team he would 
provide us with digital copies of pictures of the commanders and primary staff to 
incorporate into the division's Intranet. Unfortunately, the team failed to get back with 
MAJ Willand to secure the digital copies prior to our departure from division 
headquarters. The team will coordinate with MAJ Willand for electronic transfer of the 
information. 

In our discussion with the G3, his initial concerns were with the security aspects 
of the system. Informing him that there would be no classified message traffic permitted 
on the system, he was still concerned about the compromise of privacy act information 
(i.e., social security numbers). We assured him that the system is an internal (Intranet) 
network that will be accessible only to authorized users. Only a certain number of the 
authorized users will be given access permission to personnel records for the purpose of 
maintaining those records. 

The G3 asked where, in relation to the SIDPERS database (U.S. Army's personnel 
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database), will the new Intranet system fit in? His concern is that with the introduction of 
this new system, which is tracking similar data, twice as much time will be spent entering 
the same data. LTC Barham made the point that because SIDPERS is a higher 
headquarters information system, it is a political football that needs to be treated with kid 
gloves. All the discussion participants expressed their frustration with the current 
SIDPERS system and its inability to provide the division with timely, updated, and 
accurate data. 

Discussion turned to training and training schedules. We showed the G3 the demo 
copy of the training schedule that we put together. The point was made that not only the 
G3 but the division as a whole (G1-G6) really needs an all encompassing calendar that 
would be useful in tracking and resolving activities within the division. We noticed that 
Calendar Creator Plus, a software calendar tool, was in widespread use throughout the 
division headquarters. The development team will check with the vendor to see if the 
newest version of the software is hypertext mark-up language (HTML) compliant, which 
will enable the calendars to be posted to the Intranet. Someone mentioned how useful it 
would be to "drill down" to a battalion's page and see what kind of upcoming events they 
had on their battalion calendar. 

SGM DeAmicis gave the team a CD copy of the Standard Army Training System 
V4.0. He mentioned that V4.1 was just released or is due to be released shortly. The team 
will inquire with the program's developer on version V4. 1 and will look into how this 
program can be incorporated into the Intranet. 

The G-3 inquired about a system "chat" capability where users could conduct real 
time interactive text transmissions over the network. He mentioned that he currently 
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conducts chat sessions with members of his G-3 staff to conduct remote planning 
sessions. The idea evolved out of the need to conduct "dark night" planning sessions, 
where commanders and staffs traditionally would have to travel to a meeting place to 
conduct planning for upcoming guard training weekends. The remote chat sessions allow 
the commanders and staffs the convenience of remaining geographically dispersed and 
conducting their planning sessions on-line. Microsoft NT Server v4.0 with service pack 
2, which will reside on the division's Intranet server, comes bundled with a program 
called NetMeeting. The team has not had the opportunity to look into the program's 
capabilities/limitations but understands the program has both a "chat" and "whiteboard" 
capability. 

Potential content areas for the G-3 include posting areas for exercise operations 
orders (OPORDS) and fragmentary orders (FRAGOS). 

The capability to scrub the Unit Status Report (USR) at each echelon level, from 
company through division, was discussed. The team expressed the need to better 
understand the USR process so that we could better understand how the USR process 
could be improved through the use of the Intranet. 

MAJ Russ Gamer, a member of the G-3's staff and the division's USR responsible 
officer, was brought into the meeting to discuss the USR process and how the process 
could be simplified through the use of an Intranet. MAJ Gamer mentioned that it would 
be nice to have a dynamic copy of the USR data that could be manipulated at each 
echelon level. MAJ Gamer provided the team with an electronic copy of the new AR 
220-1, the regulation covering the USR. MAJ Gamer also provided hard copy templates 
of the USR report. 
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MAJ Bruce Shrewsberry, representing the G-l, works with Russ Gamer, playing 
a major role in the USR process. MAJ Shrewsberry draws personnel information from the 
SIDPERS database and consolidates battalion size and separate company personnel 
information. MAJ Shrewsberry puts together the division's master report, which shows 
the results and rank orders the 23 battalions and 16 separate companies in 9 personnel 
readiness categories. MAJ Shrewsberry gave us an electronic copy of his most recent 
master report to publish and include in the prototype. MAJ Shrewsberry brought up some 
ideas in reference to G-4 related applications and thought that it would be nice to 
integrate some of the G-4 related processes (i.e., lateral transfers of equipment, etc.). We 
told MAJ Shrewsberry that we had stayed away from anything G-4 related because the 
Logistics Automation System Support Office (LASSO), which is an office of four 
automators, is currently working to integrate their automated system into this Intranet 
environment. In later discussions with the G-4, it was determined that it would be 
beneficial to incorporate some G-4 related material apart from the development being 
done by the LASSO. 

Three other ideas came out of our discussions with MAJ Gamer and MAJ 
Shrewsberry. One was the idea of a suspense page under each G section. This would 
allow the G sections to post ongoing suspenses for the division. Another idea was to have 
a page under each G section that would indicate the submission frequency of all required 
reports. The third idea was to have a telephone book section under each entity section. 

All three are easy to implement and will be included in the developing prototype. LTC 
Barham mentioned that his battalion is currently working on a phone book for the 
division. We will look to LTC Barham to populate the phone book portions of the 
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prototype. 



We gave our presentation to MAJ Dimunyatz, SFC Oehmen, and SFC Smith from 
the G-2 section. They mentioned that their primary battlefield information systems 
include the All Sources Analysis System (A SA S) Warrior and MSCIMP Beta. We later 
received a demo from them on their ASAS Warrior system. We told them that the 
Intranet would be a system apart from their battlefield information systems. Some ideas 
for the use of the Intranet system include a page for routine security messages, a page for 
a G-2 newsletter, a page for Intelligence Summaries (INTSUMs), and a page for weekly 
threat updates. 

MAJ Dimunyatz said that he is often asked how many Intel soldiers there are and 
where they are located throughout the division. With a divisional relational database, 

MAJ Dimunyatz could query this information (i.e., MOS=96B) and get a return listing of 
all his Intel soldiers in the division and where they are located. All this is possible in the 
proposed personnel database. 

We met with MAJ Jose Coito, S-3 240th Signal Battalion over lunch. From the 
team's perspective, one of the most critical pieces to the division's new Intranet will be 
the development, dissemination, and implementation of policy for the new system. MAJ 
Coito said that as the new system's proponent for the Division, the 240th would look into 
the policy aspect of the new system. The thesis team is also looking into developing draft 
policy for the new system, especially as relates to content context. MAJ Coito reiterated 
that his battalion was working on developing the Division's phone book which, when put 
together, could be ported to the prototype. 

We met with representatives MAJ Dennis Davis and SFC Fuller from the G-4 
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section in the afternoon. We told them how we had not done any work to date with G-4 
related information due to the LASSO section working on porting logistics related 
information systems over to the Intranet. 

MAJ Davis said that he could break his shop into 4 entity areas: supply (X 
classes), transportation, maintenance, and, services. Information pages for each of these 
areas will be established on the prototype, along with a link to the LASSO's work. SFC 
Fuller provided the team with several service request forms to integrate into the 
prototype. 

MAJ Davis mentioned that having electronic mail in order to transmit and receive 
action items would be very beneficial. He also said that controlling who (authorization to 
a limited number of users) could submit action items and who would be able to track 
(who submitted what, when) those actions through an audit trail would be a critical 
component. 

Electronic mail will be another service that will be made available with the 
implementation of the new Intranet system. Most of MAJ Davis' concerns will have to be 
addressed in policy and procedural documentation and by the introduction of e-mail to 
the division. 

Our last meeting of the day was with CPT Rebman, who is part of a ten man 5th 
Army advisor group. He mentioned how the Intranet would be a useful medium for 
posting advisor-related information. I told him we would establish pages and links for the 
Army advisor group at the Division level and at each one of the maneuver brigade sites. 

We met with our sponsor, LTC Barham, briefly before departing the division 
area. We told him we had gathered a lot of good information and would put together a 
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trip report of the day's events. In our initial meeting back in December, LTC Barham 
identified three primary focus areas: readiness, USR, and training schedules. The 
readiness focus area and USR focus area overlap. With the USR process, the team needs 
to educate itself on the process before we can indicate how this area will be implemented 
in the Intranet environment. The production of a static master report is in the “easy to do” 
category. How to implement the rest of the USR process will take some education and 
work on the part of the development team. The training schedule focus will be expanded 
into an organization event calendar that will include the major events at each echelon 
(i.e., Division, Brigade, Battalion, etc.). There were a number of 

requirements/wants/wishes that fell into the "easy to do" category (i.e., phonebook pages, 
completed master report, digital images of commanders and staffs, etc.). Even the event 
calendars should not be too difficult. The three "long poles" in planning the next steps for 
development will be: 

• once the team becomes educated in the USR process, determining how the 
process can be simplified through the use of the Intranet 

• the development of a division-wide relational database that will be the source 
of timely and accurate information for authorized users 

• the development of the Division's Intranet system policy. The system's policy 
has got to be an all encompassing document that covers every operational and 
procedural aspect of the system 

This concludes trip report #2. At present, the thesis team anticipates two more 
visits to the division headquarters before we begin our write up. 
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APPENDIX C. DESCRIPTION OF MAJOR REQUIREMENTS 



I. Basic Intranet Design From A Divisional Viewpoint 

In order to bring the Division’s Intranet to life, we had to give it structure. The 
Division’s Intranet structure replicates the hierarchical command structure of the division 
and is the “skeleton” on which the rest of the Intranet resides. 

• Entities affected: All 13,579 soldiers currently assigned to the division will 
be affected. 

• Number of users: Potentially all 13,579 soldiers in the division will be users 

• Primary Owner: The division commander would ultimately be responsible 
for giving the authority to implement the new division Intranet. His G-6 staff 
officer would oversee the strategic level planning, implementation, and 
execution of the system. The day-to-day operational duties (adding, 
modifying, and deleting division level content, overseeing the content 
postings of subordinate units, etc) would be done by a dedicated webmaster 
(still to be determined). 

• Frequency of use: continuous 

• Frequency of update: daily 

• Mode of use by entities: All 23 subordinate battalions and 18 separate 
companies/detachments will maintain their own portions of the division 
Intranet. Password access to modify each of the 41 “sub webs” will be given 
to battalion and company/detachments by the division’s webmaster. This will 
require each battalion and company/detachment to have its own responsible 
webmaster. 

• Types of information: Unclassified information of all types is planned for the 
system. Unclassified but sensitive (i.e., social security numbers) and 
classified (i.e.. Unit Status Reporting) material will be considered in a closed 
network context. 

• Source of information: The sources of information run the gamut, from 
policies at the division level, through each entity level, all the way down to the 
company/detachment level. Reports at all levels are targets for consideration. 
Database information from the existing Standard Installation/Division 
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Personnel System (SIDPERS) will also be a source. Requests for 
administrative action or support are equally viable sources of content. 

• Current Status: The division is partly automated in that it uses automated 
software programs like word processors, spreadsheets, and standalone 
databases to assist in completing administrative tasks. They have just 
completed the installation of ten dedicated 1-800 lines and have reached initial 
operational capability (IOC) as a fully capable Internet service provider (ISP). 

• Miscellaneous information: The primary benefit this system provides the 
division with is the capability to widely disseminate timely information over a 
very broad geographic (5 state) area. 

• While on-site personnel were deep into planning access to automated logistics 

• support via the proposed Intranet, no overall design incorporating access and 
potential content for the division staff and subordinate commands were being 
addressed. 



II. An interactive administrative/personnel database 

The division’s current system of tracking personnel information is called the 
Standard Installation/ Division Personnel System also known as SIDPERS. The 
California National Guard runs its own variant of the SIDPERS system that was 
developed for the active component. 

A California National Guard recruiter enters a soldier’s personnel information 
into the system upon his/her entry into the guard. Subsequent entries or changes to the 
individual’s personnel data are done through a very antiquated process of mailing the 
source documents (promotion orders, copy of marriage certificates, etc.) to the Office of 
The Adjutant General (OTAG) in Sacramento, CA. Division personnel we spoke with 
who work with the SIDPERS system say that the system is never updated in a timely 
manner and continuously reflects inaccurate data. Another drawback of the system is that 
it has a very limited querying capability. 
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LTC Barham mentioned that the need exists to maintain a personnel database that 
could reflect timely and accurate information. The Office of The Adjutant General 
(OTAG) is currently conducting a test case with one of the division’s battalions. The test 
gives the battalion the ability to directly input and change information in the SIDPERS 
system. Beginning in October of 1997, implementation of this capability will begin at all 
the battalions in the division. This initiative will certainly improve the accuracy and 
timeliness of the information. The query limitation, unfortunately, will still be present. 
We have put together a dynamic web-based prototype which illustrates for the division 
the power and usefulness of a query able database. If the division were to choose to refine 
the prototype so it is more robust, it should be done in a manner in which the information 
from the SIDPERS database could be imported directly into the division’s personnel 
database, and updated periodically. 

• Entities affected: Hundreds of command and staff personnel would be 
affected with the increased capability to query any personnel related fields. 
The improved capability would bring to bear more informed and timelier 
decisions. 

• Number of users: Hundreds of S-l personnel would be the primary users, 
but others could also use it if provided access. 

• Primary Owner: The division’s G-l would be the primary owner of the 
system. 

• Frequency of use: continuous use on a daily basis 

• Frequency of update: daily 

• Mode of use by entities: Update capability will have to be limited to a select 
few to insure integrity of the database. Daily backups will also be a critical 
part of the system’s operation. 
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• Type of information: In the closed Intranet scenario, the use of sensitive but 
unclassified traffic (i.e., use of SSNs) will be prevalent. Personnel data will 
not exceed the sensitive but unclassified security level. 

• Source of information: Ideally, the division wants to replicate the data that is 
tracked in the SIDPERS database. The major limitation with SIDPERS is its 
limited query capability. The hope is that we will be able to import records 
from the SIDPERS database directly into a web accessible Access database. 

• Current Status: SIDPERS is the standard and will continue to be the 
standard until an Army wide system replaces it. Moving input/update 
authority to the battalion level will, without a doubt, improve the timeliness 
and accuracy of the data reflected. The query limitations are real. The ability 
to retrieve traceable information beyond the query capability of the SIDPERS 
system is all done manually. 

• Miscellaneous information: The ability to import SIDPERS records into a 
division-managed database needs to be explored. A web-based, division 
managed database will provide the command with timely and queryable 
personnel information. 

III. Readiness Reporting 

From a requirements perspective, our customer wanted us to study how we could 
simplify the readiness reporting process. In accordance with Army Regulation (AR) 220- 
1, Unit Status Reporting, each battalion (23 in the division) and separate company (18 in 
the division) must complete this lengthy report. With worksheets, the report (DA FORM 
271 5-R) is thirty-one pages long. The report is classified confidential when filled in. 
Enclosure 6 depicts the current process in DFD format. 

In accordance with AR 220-1 , all Army National Guard and Army Reserve Units 
must submit a completed Unit Status Report every quarter. According to one battalion 
commander, organizations spend about a month preparing and gathering the information 
they need in order to prepare the report. Once completed at the battalion (23) and 
separate company level (18), a representative from each of these entities travels with the 
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completed report to the division headquarters in Los Alamitos, CA. Once there, the 
reports are reviewed by the division’s USR responsible officer for completeness. A 
representative from the OTAG (the 40 th division’s higher headquarters) in Sacramento 
travels to the USR quarterly tum-in and collects the data from all the submitted reports. 
This representative currently uses a software program to enter and store the collected 
information. This data is later sent to the National Guard Bureau in Washington, D.C., 
via electronic means. 

The master report is a personnel focused readiness report that is prepared by the 
Division readiness office (DRO). Information for this report is taken directly from the 
SIDPERS database by the DRO. Even though all the information for the master report is 
taken from the SIDPERS database, commanders of the twenty-three battalions and 
eighteen separate companies are required to send master report information up through 
their command channels. The battalions and companies have different methods for 
acquiring this information from their subordinate entities (i.e., companies and platoons). 
LTC Rod Barham uses a Microsoft Excel spreadsheet that he sends to his subordinate 
commanders as an attached Multipurpose Internet Mail Extension (MIME) file to an 
ordinary e-mail message. Upon completing their portion of the spreadsheet, they e-mail 
it to LTC Barham, who in-tum submits the consolidated information to his higher level 
commander. LTC Barham’s model can be adjusted for use at any command. The 
division uses a Master Report, which can just as easily be adapted for use by other 
commands. 

• Entities affected: Literally hundreds of people would be impacted by the 
introduction of a web-based Unit Status Reporting system. Travel for the forty 
plus personnel who travel to Los Alamitos every quarter could be eliminated 
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resulting in a significant cost saving to the division. Working copies of the 
report could be passed back and forth electronically via electronic mail until 
the division readiness office was satisfied with subordinate entities final 
products. 

• Number of users: Every person in the division directly involved in division 
readiness reporting would be involved. Estimate of 100 personnel. 

• Primary Owner: The Division readiness office 

• Frequency of use: daily 

• Frequency of update: the draft USR reports could be passed back and forth 
as necessary 

• Mode of use by entities: multiple update 

• Type of information: The USR is classified confidential when it is filled in. 
The master report is an unclassified document. LTC Barham’s report is also 
an unclassified document. 

• Source of information: Army Regulation 220-1 : Unit Status Reporting and 
the division’s master report 

• Current Status: Processes are explained in paragraph above 

• Miscellaneous information: The requirement from the division readiness 
office is to have a dynamic copy capability where a subordinate entity could 
download a blank report, fill it out and send it back to the DRO for review. 
The DRO could then either accept the report or send it back to the submitting 
entity with comments. When a revised edition of the report is completed it 
could again be submitted to the DRO for a second review. This would be an 
iterative process until the report is finally accepted by the DRO. 

IV. Training Scheduling/Event Planning 

A high priority requirement was to develop an electronic means of disseminating 
scheduled events. The desire is to have a divisional calendar which would depict all of 
the division level events (i.e., guard weekend events, major field training exercises, 
ranges, etc.) 
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• Entities affected: All 13,500 members who have a personal computer and a 
modem could check the web-based calendar for timely scheduling information 

• Number of users: see above 

• Primary owner: Either the G-l or G-3 would maintain an up-to-date 
schedule. Most likely the G-l. Personnel staffers at all echelons (i.e., brigade 
S-l s and battalion Sis ) will most likely want to maintain their own calendars 
at their own level. 

• Frequency of use: continuous 

• Frequency of update: as necessary when events are added, changed, or 
deleted 

• Mode of use by entities: read only 

• Type of information: scheduling 

• Source of information: primary staff input 

• Current Status: Division uses calendar creator plus a calendar application. 
These calendars are manually distributed or sent via fax 

• Miscellaneous information: In regards to policy, someone will have to make 
the decision who will maintain the division’s calendar. Typically the G-3 has 
most of the input (range schedules, field exercises, etc.) but the G-l is the 
commander’s administrative arm. 

During requirements gathering, we interviewed each of the four primary staff 
elements (G-l through G-4). During this process we gathered some requirements that 
were not necessarily a priority but fell into the “nice to have” category. We gave most of 
them consideration if they could be done very quickly without too much difficulty. The 
following paragraphs speak to some of the “nice to have” we put in the prototype. 
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APPENDIX D. GUIDANCE FOR THE MANAGEMENT OF ARMY WEBSITES 



Guidance for the Management of Army Websites 
30 October 1996 

Releaser: LTG Otto J. Guenther, DISC4 



1 .References: 

A. Public Law 100-235, Computer Security Act of 1987. 

B. AR 360-5, Public Information (31 May 1989). 

C. AR 25-55, Army Freedom of Information Act Program (10 Jan 1990). 

D. AR 380-19, Information System Security (1 Aug 1990). 

E. AR 380-5, Department of the Army Information Security Program (25 Feb 1988). 

F. AR 340-21, Army Privacy Act Program (5 Jul 1985). 

G. AR 25-1, The Army Information Resource Management Program (24 May 1991). 

H. Memorandum, Deputy Secretary of Defense, 17 Feb 1995, Subject: Clearance 
Procedures for Making Electronic Information Available to the Public. 

2. Purpose: This message provides initial guidance for the establishment and operation of 
Army world wide websites ("websites"). A final policy is being coordinated. 

3. This guidance applies to all Army organizations that maintain publicly accessible, 
non-restricted websites. 

4. The world wide web (WWW) is an efficient and effective means for the U.S. Army to 
share information. Army websites should focus on providing value-added information 
services and products to the organization's users, customers, the Army, and the public 
through the sharing of accurate, relevant information. Army Websites can enhance the 
execution of the Army's mission through information sharing, and save resources 
currently expended on traditional means of communication. To ensure that the Army 
fully leverages the capabilities of the WWW in a manner that is efficient, focused on 
saving resources, and moving toward a digital environment, the following guidelines are 
provided. 

5. The organization's leadership should evaluate the website's ability to provide value- 
added service, enhance the execution of the organization's missions and functions, or 
realize efficiencies when determining whether their organization, or subordinate 
organization, should develop or continue to maintain websites. 

6. The organization's leadership is ultimately responsible for the content of the 
organizations website and compliance with Army policy. The organization's leadership 
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will have knowledge of the websites operated by their command and subordinate 
commands, and the information provided to the public through these websites. 

7. Army websites will provide the following information or hyperlinks to the following 
information on their homepage: (a) organization missions and functions; (b) 
organizational structure, listing or hyperlinking to parent and subordinate command or 
organization websites (organizational charts containing individuals' names and other 
personal information should not be uploaded unless privacy and security concerns have 
been addressed; posting such information for members of deployable units and others in 
sensitive positions could make them potential targets of hostile organizations or 
individuals); (c) electronic mail address, phone number, or mail address of point of 
contact responsible for the website content; (d) a hyperlink to the U.S. Army homepage 
(http://www.army.mil). 

8. No classified, unclassified but sensitive, information that cannot be disclosed under 
the Privacy Act, For Official Use Only (FOUO), or Freedom of Information Act (FOIA)- 
exempt information (such as draft policies and regulations, or pre-decisional information) 
will be made available to the public through WWW. Each organization will institute a 
review process to ensure that information provided on their website is current, timely, 
and cleared for public release. 

9. To ensure that a user entering any Army website can reach a central source for 
accessing all other Army websites, every organization that maintains a website must: (a) 
register their homepage with the U.S. Army homepage webmaster through the online 
registration form found on the Army homepage; (b) provide a hyperlink to the U.S. Army 
homepage on their homepage. 

10. Personal use of government resources generally is improper. Hyperlinks on official 
Army websites to personal homepages or websites are prohibited. 

11. Commercial advertising on official U.S. Army websites is prohibited. Corporate or 
product logos and trade marks are considered commercial advertisements, and may not 
be served from official U.S. Army websites. 

12. Website/document points of contact ("webmaster") will: (a) ensure that information 
published on their website is accurate, timely, represents the official Army position, and 
is properly cleared for public dissemination; (b) ensure appropriate security and access 
controls are in place, commensurate with the perceived threats, and to ensure that 
information which is classified, unclassified but sensitive, information that cannot be 
disclosed under the Privacy Act, For Official Use Only (FOUO), or Freedom of 
Information Act (FOIA)-exempt information (such as draft policies and regulations, or 
pre-decisional information) is not made available to unauthorized individuals or 
organizations; (c) provide the highest possible level of assurance that information made 
available to or received from the public does not contain malicious software code such as 
viruses, trojan horses, logic bombs, bacteria and worms, or if it does, to sufficiently 
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notify the user before the download of such information begins; (d) respond to customer 
or user email and direct queries or requests for information to the responsible party within 
the organization; (e) ensure that the organization's website provides point of contact 
information. 

13. Point of contact: Mr. Christopher Unger, webmaster@hqda.army.mil, commercial 
(703) 275-9500, DSN 235-9500. 

14. One Voice for the Army! 



<Picture>to u.s. army homepage 
<Picture>questions for webmaster@hqda.army.mil 
<Picture>security & privacy notice 
<Picture>last update: 19970115 
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